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Ih this Issue 

The HP ORCA (Optimized Robot for Chemical Analysisl system is a different kind 
of roboL In the words of Gary Gordon, one of the robots designers and coauthor 
of the article on page 6, "Why would a company choose to optimize its first robot 
for initially doing chemistry instead of. say, circuit board or instrument testing? 
Tile answer is that there was a pressing customer need. HP is a major supplier 
of analytical instrumentation such as gas chromatographs. Such instruments 
help ensure the cleanliness of the food we eat and the water we drink by detect- 
ing harmful contaminants such as pesticides and industrial wastes. The first 
step in detection is sample preparation, ft is tedious, time-consuming, and error- 
prone — in short, a ripe candidate for automation. Sample preparation entails 
reducing a matrix such as apples, pills, or blood serum to a clear concentrated fluid suitable for injection 
into the chromatograph. It involves such wet chemistry operations as crushing, weighing, centrifuging, 
extracting, and filtering. These are not enriching tasks for most people, yet tens of thousands of chemists 
are locked Into the tedium of their repetition. What scale of sample-prep automation is appropriate? The 
variations from one procedure to the next rule out dedicated rnstruments. Instead a robotics approach 
fits best, interfaced with common laboratory apparatus such as centrifuges and balances. A search for 
commercial robots showed that they were typically too big and heavy, were optimized for precision as- 
sembly such as installing machine screws, and only accessed small work volumes. The HP ORCA robot 
system is quite different. It manipulates small (subkilogrami objects such as test tubes and probes in and 
out of tight places within a huge several-cubic-meter work volume at lively speeds. Much of the contfibu- 
tion of the HP ORCA system lies in the intuitive software interface and a gravity-sensing teach pendant 
that simplifies teaching the robot new tasks. The HP ORCA system can be easily integrated with other 
applications to create sophisticated, turnkey, automated systems/' 

In object-oriented programming technology, an object consists of some data and the methods or functions 
that can be used to access or operate on the data. Object-oriented programming is gaining wide accep- 
tance for the development of large software systems because it makes developers more productive and 
makes software more maintainable and reusable. Central to many large commercial applications is a 
database management system, which allows efficient storage and flexible retrieval of large amounts of 
data. HP OpenODB (page 20) is an object oriented database management system designed to support 
complex commercial applications, ft combines a fast relational database management system with a 
specially developed object manager and has a client/server architecture, HP OpenODB provides tools 
that allow developers to use object-oriented modeling techniques to build a database. For data access, 
it has a procedural language called OSQL, which is based on the industry-standard SQL (Structured 
Query Language). It also offers run-time performance features such as late binding and schema modifi- 
cation and features to control access to data and ensure data integrity. The OpenODB model differs from 
other object models (there is no standard object model); how and why are explained in the article. 

The HP Ultra VGA board is a video accessory card for the HP Vectra family of personal computers. (The 
same functionality is embedded in HP Vectra 4B6/U PCs.) Using hardware accelerators, the Ultra VGA 
board enhances video performance for graphics-intensive applications. It offers display resolutions up 
to 1024 by 768 pixels, refresh rates up to 72 times per second, and up to 256 colors, Software display 
drivers allow applications to take advantage of the performance enhancements. The article on page 31 
traces the ancestry of the Ultra VGA board— from CGAto HGC to EGA to VGA— and discusses its design, 
including the hardware/software trade-offs, the use of a custom integrated circuit and video RAM 
memory devices, and the driver implementation. 

POSfX stands for Portdble Operating System Interface, a standard of the Institute of Electrical and 
Electronics Engineers. It defines a standard operating system interface and environment that guarantee 
that any POSIX application will run under any operating system that supports the POSIX interface, which 
is simitar to the UNIX* operating system. As explained in the article on page 41, the MPE/iX operating 
system, which runs on HP 3000 Series 900 computer systems, does just that. In MPE/iX, the functions. 
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servJceSr and application program interface spactfied in the POSIX standard are integrated with HP's 
MPE XL operating system. MPEXL applications can access POSIX files and POSfX applications can 
access MPE Xi files. Existing MPE XL applications are not affected. The frrtegration team had no trouble 
visualizing MPE XL and PDSIX as one operating systein, but found challenges in the areas of directory 
structure, file naming, and security. The article describes their solutions. 

Six papers in this issue are from the 1992 HP Software Engineering Productivity Conference.*^ HP's 
MecJica! Systems Unit has been researching and experimenting with methods of preventing software 
failures in safety-critical medical applications. The paper on page 47 describes their software hazard 
avoidance process, a combination of testing for hazards and analysis aimed at prevention. •- If software 
can be reused, so can software tests. With this in mind, two HP printer divisions are implementing a soft- 
ware test library management system to make it easier to locate existing tests, determine their suitabil- 
ity, and combine them into test suites (see page 53). ^ While the value of software inspections as a part 
of software development is well-accepted, in a busy fl&D lab it's not always easy to get an inspection 
program started, maintain it once started, and meaningfully measure its success. The article on page 60 
discusses one HP division's successful efforL*- Total Quality Control, orTQC, is a process improvement 
technique used extensively within Hewlett-Packard and by other companies. In the article on page 64, 
software engineers at HP's Imaging Systems Division tell how they successfully applied it to reduce the 
time required to localize, or translate, software text used in medical diagnostic ultrasound systems. •" A 
substantial number of engineering hours are spent developing system administration applications for the 
HP-UX* operating system, resulting in a major challenge in achieving user interface consistency. The 
article on page 71 describes the design of a special application program interface that enforces consis- 
tency and shields developers from the underlying user interface technology. ^ Typically, error-handling 
code is dispersed throughout a program. In the article on page 30, Bruce Rafnel argues that this makes 
programs hard to write, read, debug, enhance, and reuse. He suggests handling errors in programs as 
they are handled in a database transaction recovery mechanism: the entire transaction is canceled as if 
it had never occurred if an error is detected anywhere in its processing. 

R.P Dolan 
Editor 
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This photograph of the HP ORCA analytical robot in action was taken by author Gary Gordon with project 
manager Greg Murphy controlling the robot and artist Nicola Gordon providing art direction. 



Wliat's Ahead 

In the August issue we'll have articles on HP's new line of high-brightness AflnGaP LEOs, the HP Tsutsuji 
logic synthesis system, the HP ScanJet lie color scanner, the HP-RT (real-time) operating system design, 
the mechanical design for the HP 9000 Series 7Q0i industrial workstations, the computation task distribu- 
tion tool HP Task Broker, and three papers from HP's 1992 Software Productivity Conference— one on a 
defect management system, one on productivity and C++, and one on a modeling tool for real-time soft- 
ware systems. We'll also have a research report on surgical laser control. 



KP'UK is based on and is compatibte with UNIX SystEm Laboratories" UNIX* operanng system. It also coruplies with K/Open'?* XPS1, fOSlX 1003.1 

and SVID2 interface specifications 

UMX IS a registered Uademark ci( UNIX System Laboratories fnc. in the U.S.A. and other countnes. 

X/Open LS a trademark of X/Dper^ Company Limited m tt\e UK and oihet coantnas 
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ORCA: Optimized Robot for Chemical 
Analysis 



This analytical PC peripheral is a congenial assistant a sophisticated 
robotic teaching environment, and an interesting study of robotic 
architecture. Although optimized for the analytical laboratory, it also 
has applications in electronic test quality assurance, and the clinical 
laboratory, where heavy commercial assembly robots are unsuitable, 

by Grary B, Gordon^ Joseph C. Roark, and Arthur Schleifer 



Analytical chemists currently spend approximately two 
liiirds of tJieir lime preparing samples to be placed into in- 
struments for analysis. This sajnple pieptu-ation is not only 
tedious, but also subject to errors mtroduced by huniaii in- 
teraction and himian vaiiation. At the same time, an ever- 
increasing number of samples to be an^dyzed eacli year 
coupled with a declining pool of skilled chemists has re- 
sulted in a pressing need for automation to improve the 
productivity of the analytical laboratory. 

Samples arrive in the laboratory in liquid, solid, and gtis 
form. Quantities range from Uie microgram or microliter 
size to tajik cars filled with t ons of material. The instru- 
ments tli at are used to analyse these samples, such as gas 
and liquid clu omatographs, usually require that die samples 
be cleai>ecl up to remove aJnwst all of the components of the 
material except for the chemical cornpomids of inrerest. 
Sample preparation involves many steps, including weigh- 
ing, grinding, liquid pipetting and dispensing, concentration, 
separation, and chemical reaction or <lerivitization. In n\ost 
cases this work is done by hand, although instruments are 
available that peifonii jiarticular prepaiiiticjn operations. To 
provide a system that ijerfonns a majority of the operations 
required for samjDle preparation requires a great deal of 
flexibility and versatility. 

A robotic system seemed like die appropriate solution. But 
what type of robot? Kobots designed for manufacturing and 
assembly me not well-suited for die a^ialytical laboratory 
Tlie requirements lor a laboratoiy robot go beyond the tradi- 
tional chaiacteri sties dissociated with manufacturing sys- 
tems. Since today's laboratory and instruments aie designed 
lV>r people, automation is difficult because not all the pieces 
of the laboratoiy are designed to work with robots. In con- 
trast, assembly Lines redesign die envarojuuent, process, and 
products to work easily with robots. It will be a long time 
before the chemical laboratory retrofits Tor automation. 

Manufacturing robots in general are optimized for a differ- 
ent problem: very acciurate positioning of often heavy pay- 
loads j in seldom re ciiu figured enviroiuncnts. These robots 
perform a small number of tasks veiy precisely in a small 
work volume, hi contrast, an analyiictil robot is required to 
perform a viide range and number of tasks over an existing 
labor at oiy workbench and interact with existmg laboratoiy 
containers and instRUTients. The same might be said of a 



robot for many other applications, such as electronic test^ 
quality assurance, or chnical laboratory' analysis (see "The 
IIP ORCA System Outside the Ajialytical Laboratory" on 
page 9). To lit into existuig laboratory- environments, a robot 
must be instalJable without modification to die laboratory 
furniture. This will allow both rapid installation and easy 
i-elocation of the robot \\qthin the facility. The robot's work 
volume must allow the robot to ready the entire bench area 
and access existing analytical mstrumervts. There must also 
be sufficient area for a stockroom of supplies for unattended 
operation. 

Tlie laboratory robot can be involved in tlnree types of tasks 
during an aiuiljtical exiierimenb The furst is sample Intro- 
duction. SauipJes anive in a variety of containers. It is time- 
cons[imiMg ^uid a potential source of error for the operator 
to transfer the sample from the udginal container to one 
diat is acceptable for automation. The robot, however, can 
be tiauied to accept a number of different sample trays, 
racks, and containers, and mtroduce them mto the system. 




Fig. 1. l^^iitiil aiialj-tical laboratory work volume. (Piiato reproduced 
with pcimiission of Scilec SA. Laus^iniie. SwitzerlandO 
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The second set of tasks for the robot is to transport tlie sam- 
ples between indl%idua] dedicated automated stations for 
chemical preparation and instnmientai analysis. Samples 
must be scheduled and moved ber«^een these sUttons as 
necessary^ to complete the analysis, Tlie third set of tasks for 
a robot is where flexible automation provides new capability 
to the analytical laboratory; There will always be new chem- 
ical sample that require analysis steps that have ne\^er been 
aytoniated. To prototype the automation of such steps, the 
robot must be programmed to emulate the human operator or 
work with various de\1ces. This last use may require consid- 
erable dexterity for a robot. All of these types of operations 
are required for an effective laboratory robot 

Additional considerations for a laboratory robot are that it 
be the size of a himian arm and have the dexterity needed 
for interaction with current chemical ins tni mentation. Inter- 
changeable end effectors (robot fingers) are required to al- 
low the robot to work with the wide range of existing con- 
tainers and consimiables used in sample preparation. The 
robot should provide a simple and clean work area with no 
external wires to catch on glassware or instruments. 

After evaluating a number of existing robots for this applica- 
tion, it was finally concluded that a robot could be designed 
that was optimized for chemical sample prcp^iration and 
other applications that have similar requirements, as nien- 
tionpd above. The results of this analysis iirt^ the concept 
and design described in tMs article. The new HP analytical 
robot is called ORCA, which stands for Optimized Robot for 
Chemical Analysis. Fig. i shows it insUilled on a lab bench. 

An anthropomon^hic arm moimted on a rail was chosen as 
the optinntm configuration for ihe analytical laboratory The 
rail caji he lo<"ated at the front or hack of a workbench, or 
placed in the middle of a talkie w^hen access to both sides of 
tlie rail is required. Simple software commands permit mov- 
ing the ann from one side of the rail to the other w^hile main- 
taining the wrist position (to transfer open containers) or 
locking the wrist angle (to transfer objects in virtually any 
orientation). The rectilinear geometry, in contiai^t Itj Hit* 
cylindrical geometry used by many robots, permits more 
accessories to he placed witidn the robot workspace and 
provides im excellent match to the laboratory bench, Move- 
nient of all jtjints is coordinated tlirough softw^are. wliich 
simp lilies the use of the robot by representing tlie robot 
positions and movements in the more familiar Cartesian 
coordinate space 

The physical and performance specifications of the HP 
ORCA system are shown in Table I 

A robot alone does not satisfy the needs of laboratory auto- 
mation. Besides t he physical aspjects of the roljot, the system 
must be able to work with other devices, computers, and 
software. Tlie other m^or development of the ORCA project 
was the control software, which is called MeUiods Develop- 
ment Softwaie 2A\ or ME>S. MDS runs on the flP Vtctra and 
other PC-compatible computers under the Microsoft.^^' Win- 
dows operating envirormienl. Il is designed ttj allow instiii- 
ments to be added easily to the system. By the use of indus- 
try-standarrl conuminicatJon interfaces, MDR can cuiiH^ure 
devic^eSt and i}rocet]ures caii be developed to contml miliI 
coUect data from exiemal devices. It is designed to be 



ORCA Robot 
Arm 

Uegrees of freedom 
Reach 
Height 
Rail 
Weight 
Precision 
Finger tjavel 
G ripper rotation 
Teach pendant 
Cycle tinte 

Maximum speed 
Dwell time 

Payload 

Vertical deflection 

Cross-sectional 
work envelope 

Power requirements 

Operating 
environment 



Table I 
Arm Hardware Sp ec if i cations 

Artit ulared. rail-mounied 

Six 

±S4cm 

78 cm 

land 2 m 

8.0 kg 

±0.25 mm 

40 mm 

±77 revolutions 

Joy stick with emergency stop 

4 s (move 1 inch up, 12 inches 
across, 1 inch down, and back) 

75an/s 

50 ms typical (for moves within a 
moti<m) 

0.5 kg continuous, 2.5 kg transient 
[with restrictions) 

< L5 nun at continuous payload 

Im^ 

lOOV, 120V, 220V, or 240V (+5%, 
--10%), 350 VA, 47.5 to GG flz 

5X to 3S^C at to 9m Rtl 
(noncondensing) 



exteasible; new modules can be added to tlw system at mn 
time, MDS is also tlesigned to be remotely controlled by 
other programs. This allows the laboratofy robot system to 
be a server in a hierarchic^al automation system. 

Most, previous robots were progiammed in coordinate space 
wit li romiHiter-like languages, Tiie MP ORCA system, on the 
other haiui, is taught by first demonstrating to t lie j tjbot a 
tnove, using another new development, the gravity-sensing 
teach peruiarit (see "Gravity-Sensing Joy Sticky*" page 12). 
The move is then given an intuitive name, for example 
get.testtube, I^ter, this or any other move can be called out 
by name luirl built into higher-level procedures. Simple to 
giasp yel powerful, this concept is easily expanded to (con- 
trol an entire bench! op (»f laboratoiy equipment. Tlie user is 
freed to tliink about the greater task at hand rather tiian 
specific software details. 

Having these components leads to our vision of the auto- 
mated laboratory bench. For the first time, il is possible to 
[jrtjvide automation for the analytical laboratoiy all the way 
frotu sample introduction to the final report witln>ut hmiian 
ir\lervention. TJie OP ORCA system provides the physical 
gii(e to tie together the individual chemical instruments as 
well as the infonuation or data bus, so tliat the system can 
te(|:iesl. iuquire, and distiibute infonuation to all coniponents 
of tlu' wurkbench. 



.Flint* iyf)8 Htnvlx^it-PrK'kaiil.Ioiimu! 
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ORCA System Overview 

The HP ORCA system is shown pictorially in Fig. 2, which 
shows ihe major functional blocks. In the Ijioadest sense, 
the input to the HP ORCA system is a high-level command, 
such as to analyze a drug (such as aspirin) for puritj'. Near 
the output end, the ORCA electronics deliver strings of mil- 
Uons of individual millisecond-by-millisecond commands to 
the six robot servos. To keep this transformation task from 
becoming overwhelming, it js broken down into manageable 
hierarchical levels. 

Input to the system begins with a user interacting with the 
PC, which is running MDS, MDS provides experiment con- 
trol through its own programming language, hi conjunction 
with other applications on the PC, such as HP ChemStation 
software, MDS can also be used for chromato graph control. 
MDS consists of a core system, wtuch is used to build and 
run reusable tasks called procedures, and one or more 
modules, such as the robot module. 

The MDS robot module accepts MDS procedure commands 
for controlling the robot and parses the commands into end- 
points for each of die segments of the robot moves, A typical 
robot move might he from a starting point taugtvt to the robot 
an d named ve r B a i a n c e I o an ending p oint named n B a I a n c e . 
These endpoints define straight-line segments. The output of 
the MDS robot module, ajid in fact the output of the PC, is a 
string of taught Cartesian waypoints representing the robot 
moves, sent every few secor^ds over an HP-IB link (IEEE 
488, lEC 625) to tJie kinematics processor. 



The kinematics prbcessor consists of software running on a 
dedicated 68000 microcomputer. One of its tasks is coor- 
dination of the six axes of the robot to provide smootli mo- 
tion and airival at the Cartesian endpoints. This is acconv 
pLished in part by interpolation. The kineniaiJcs processor 
aJso handles tool offsets, so that, for example, a test tube 
can be rotated about \is lip instead of its point of support. 
The fmal fimction of the kinematics processor is to compute 
the acceleration and deceleration profiles and the speed of 
each move so that motion is smooth and the axes* speed 
limits are not exceeded. 

Physically, the kinematics processor shares a cabinet with 
the sen^o power supply This cabinet has no controls and 
can be located out of the way under the bench. The output 
of the kinematics processor is coordinated position com- 
mands in joint space for motion along the path, sent over an 
R&422 bus to the robot at a frame rate of 26 Hz. 

The last functional block of the system is the joint interpola- 
tors, w^hlcli are distributed throughout the robot. The 25'Hz 
commands from the kinematics processor are coarse 
enough that they w^ould cause the robot to \ibrate and 
growl so instead they are linearly interpolated into L25- 
millisecond demand signals, w^hich are sent to the digital 
ser\^onie c h ai^isnis* 

i continued on page 101 
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Fig. 2. ORCA robot system diagram. 
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The HP ORCA System Outside the Analytical Laboratory 



There are many spplicaiions in jm^ustry wtiere the pfec^£iQ^ of a manufactufing 
robe! IS TO^ required Often, in fact, such robots are genuine misfits. Tl?ev ^e 
costly, iJuHcy, h^vy, and tOG cnmplox to program for ttiese simptef jObs The HP 
ORCA system, m the ottmr hand, is much beUB suited fer the^ Jigfiter tasks It 
wetgfis 1/1 D as much as te mdustrral relatives, yet is jtist as teiiable, ar>d (T is far 
easier to use because it betiaves like an appliance or a PC peripheral The rotxrt 
can be connected to a PC. shown a task to do, and put to work without much fuss 

Theie are numefous smal] applications in maoufactunng where one might not 
normally think of using robots They inclyde many of the r^titive tasks people 
now perfomi in assembly, test, and quality assurance. 

At HR two areas being looked at are instrument fiont-panel circuit board test and 
instrument final test. Front-panel controls are not very accessible efectranicafly, 
and typically require human intervention to verify the operation of knobs, switches. 
and displays These panels are quite amenable to robotic autamatinn. Robotic 
fingers can manipulate controls, and earned sensors can monitor displays. Such 
robots fulfill a niche in medium -scale assembly, where the number of products to 
test E$ too many to do by hand, yet not enough to justify designing, building, and 
keeping track of hard-tooJed test fixtures 

Other manufacturing uses lie m assembly tasks for which the HP ORCA system's 
Q25-mm precision is sufficient. This ruies out board loading and fastener inserting. 
On the other hand, as an assembly operation is studied, it often becomes apparent 
that there are many tasks in which dramatic savings and quality improvement can 
be had through robotics. Two examples are pick-and-place assembly and adhesives 
application 

The ORCA group at HP was encouraged when other HP groups came lo us and 
wantetl robots to try out. Four early users were in two areas; gas chromatograph 
manufacturing at HP's Little Falls site in Wilmington, Delaware, and column manu- 
facturing at the Soentitic Instruments Division in Palo Afto, California. The following 
story relates how the ORCA/NC [adie project came about at Little Fafis 

Tlie ORCA/NC Lathe Project 

The ORCA/NC lathe profect conceived in a typical HFaisleway conversation, was 
initiated to address both current business needs and visions for the future A shop 
supervisor at HP's Avondale. Pennsylvania Division, where many HP ORCA system 
components were fabricated and assembled, was able to bait an R&D manager 
with the dream of a robot building itself The manager promptly found a prototype 
unit to donate to the shop, and an investigation of potential applications began. 
Five months later, the latest-model HP ORCA system was operating an unattended 
NC lathe 

Potential shop applications for a small flexible robot incfuded the transfer of parts 

between hydraulic presses in a sequence of slaking operations, the loading of 
components on a pneumatic mamfold, and the loadmg and unloading of parts on a 
machine tool, such as a lathe or mill The application of the lathe loader was 
chosen because l\ was the simplest in concept, It contributed to profitability by 
usmg outdated equipment (a ten -year-old lathe) and by reducing the shop cost 
driver rate, an important metric determined in part hy the total of unattended 
machining hours, 

The experfence gained in the lathe loader project was expected to provide a 
knowledge base for future projects^ It would help in establishing guidelines, plan- 
ning resources, and scheduling more complex applications, Also, an understanding 
of the HP ORCA system s capabilities with respect to the fabricatmn business was 
needed. The experience objective was made explicit because other lathe autoload- 
ers exisi that are more accuratR and simpler in design than the HP ORCA system. 

The project team consisted of a fabrication process engineer, a tooling designer, 
and a journeyman machinist. The first challenge was positioning ORCA on the 



lathe We wanted to access the full wfdtti of l^talfie so ws chose to bolt ORCA's 
rait onto the n^chme bed and operate the robot CfflT^etely witfim the lathe 
shields. Although the OfiCA rail ends are outside the shieids, this decisiom meant 
that the robot would be operatrng m an envrrof>ment with coolant and metal chips 
Since the lathe is still used 80% of the time im tar-iml jobs, the robot is protected 
w^n not in use by being parked tmhind the twrret under a ptastEc bag ORCA- 
loaded jobs are nun without coolant and the robot is isolated from chips by a 
telescoping cover that eirtaids over the rail cover 

The ORCA/NC lathe system includes an ORCA robot, a Hardjnge HNC lathe, an HP 
Vectra QS/20 PC, and an optoinierlace board The custom hardware consists of 

four part staging magazines, special grippers for the robot, a V-block, and a sec- 
ondary rail cover The vertical magazirtes are mounted across the lathe bed behind 
the lathe turret and hold 75 parts each The grippers are oriented such that the 
ajtis of the gripped part is perpendicular to ORCAs twist axis The V^block is self- 
centering and spring- loaded, and is mounted on the lathe turret, The secondary 
telescoping rait cover iS attached to ORCA's torso casting. 

In one cycle of the ORCA/NC process, running 50 seconds, the robot removes a part 
from the magazine, then pushes the part into the V-block and moves to a safe posi- 
tion. The lathe turret moves so that the V-block stuffs the part into the collet. The 

collet closes, the part is machined, the spindle stops, and the collet opens. ORCA 
removes the part and drops it down a slide leading to a box of completed parts 

The HP ORCA system and the specialized tooling were set up m a lab for deveiop- 
meni and moved onto the lathe two weeks before startup. In the lab, parts of the 
overall concept were simultaneously prototyped, then tested together For exam- 
pie, the.custom gripper fir^gers wejb revised five times The purpose of two of the 
revisions was to increase the maximum gripping force transmitted to the part, 
ORCA's grip had to exceed the holding force of the magaime and V-btock by 
enough force to pick and place parts reliably. 

Critical requirements for success were robustness over time and the ability to run 
for one shift without operator intervention. Robustness is defined as the ability to 
run day after day without a crash or robot recalibrahon or repair The application 
ran in the lab for thousands of cycles, 

Overall system contnol is vested in an ORCA MOS program that calls robot submu- 

tines and starts, pauses, and stops the lathe program via the interface board. To 
start the application cycle, the lathe program is loaded and started, and then the 
MDS program is started The robot positions within the move subrcutme programs 
were rough -taught with ORCAs joy- stick teach pendant and refined by keyboard 
input. Accuracy and repeatability of the movements were further enhanced by 
unidirectional programming. 

The ORCA/NC system is currently used to machine two brass and aluminum valve 
stems. Only one part was used in the system's development. The other part was 
implemented by the machinist two months after release of the application. In six 
months of operation, about 16 hours per week, there have been no problems. This 
is partially hecause of the robustness of the system and very much because of the 
ms^ of use of the system software. 

The ORCA/NC lathe project met every initial ob|ectiva is a good example of team- 
work, and has become a shop showpiece. The machine shops at Avondale were 
bought by two former managers in November of 1992, when HP moved to Little 
Falls. The HP ORCA system continues to run 16 hours per week at the new company. 
American Mar^ufacturrng Technology. 

Nancy Adams 

Manufacturing Process Etigineer 

Little Falls Operation 
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Mechanical Design 

Robot design benefils greatly from a careful optimization 
of lightness, stiffness, speed, and payioad. j\iiplanes seem 
altiiost simpler in comparison, with some being able to ciirry 
1()()% of their empty weight, compared to lCI%to 20% for 
robots. 

Playing off against the peif ormance goals were economic 
considerations, so exotic materials such as titaniimi and 
carbon fiber were not seriously considered. Further, with 
the continuing shrinkiJig of eleclronics. a ck^cision was made 
to imbed much of it in the structiu'e itself. This diminished 
the payioad slightly, but greatly simpUfied the wiring and 
improved the reliability. 

The ORCA industrial design achieves other less-tangible goals 
with little or no additional expense. It provides a smooth 
slmrture for easy clemming, accessibihty for maintenance, a 
con^pact design for dexterity in tight places, and aji attempt 
to achieve pleasing lines. 

OR(^A, unlike any other commercial robot, is an iiJithio|K>- 
moipliic shell or exoskeleton, with its chiimliers tightly 
packed with six axes of serv^o control electronics. Fig, 3 
shows an ext:>loded view. The shells are of alimiuium, cho- 
sen over plastics for thermal conductivity. They draw out 
what httle heat is generated by the ptilse-width-modulated 



servos, and spread it over the surface of the robot, where it 
is dissipated by convection. The shells are ribbed intern a]ly 
for torsional rigidity^ so that the robot is mechanically sonnd 
with the covers removed, allowing easy senice, 

ORCA is scaled roughly to the proportions of humans. The 
similarity continnes with its ^^nniscles^^ts motors — which 
are physically displaced toward the tonso; the elbow and 
wrist motors are sittiated at the shoulder. This reduces the 
static moment loads the robot miLs! carr^' because of its mvn 
weight. 

Paiticnlar effort went into refming the hand to cut weight and 
bulk to a minimnm, One interest htg feature is that the axes 
that pinch and rotate \\\e fingers are coupled mechiinically 
anti in software. The fingers are moimted to paiallel gear 
racks, which are opened and closed by spinning a piivion 
gear thai engages rhcm l>otli. Without coupling, whenever 
the fmger bar was rotated, it would wind the finger racks 
aiound the center pinion gear, open the fingers, and drop the 
object. The easy solution is to feed a proportional con"t?etion 
signal to the pinch serv^o any time tht^ fmger bar Is com- 
manded to rotate; software is eheaijei^ Llian niecbanisms. 
Fig. 4 shows the interior of the h^md. 

Because of the immense advantages of keeping the bant J 
hglu and small, gear technoiogj^ was pushed ne^u" its liitiits. 
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Fig- 4. Interior or robot haiici. 

Hardened ground geaiB and tight machiniiig tolerances are 
employed to maintain the five-year minimuin lifetime goal 
for all mechanisms* 

ORCA is supplied mounted on aii opticaJ-bench-style table- 
topj which comes in several sizes. This surface forms a 
stable platform, and its grid of threaded holes provides con- 
venieiU attachment points as well as reference locations for 
instniments and accessories. A linear rail assembly is fitted 
to either the rear, die front, or the centerhiie of the surface* 
The chassis contains the rail motor, which propels the torso 
by engaguig a steel-cable-reinforced plastic chiiin stretched 
tightly alongside the rail A simple flat cable similar to that 
used in prmters also folds into the rail ca\ity and carries ilc 
power and the serial ORCA bus, wliich affords bitiireetional 
communications with the six robot joints. 

The most mterestiiig feature of the shoulder and elbow 
joints is their harmonic drive reduction units, shown in 
Fig. 5» Tliese drives tise a ring gear w^ilh internal teeth, 
which engages a llexible inner gear shell. The flexible huier 
gear has slightly fewer leeth than the* outer rigid ring gear. 
For example, in the shouhler reducer, die ring gear has 102 
teeth, while the flexible gear has 100 teedi. Lobes inside the 
iiuver flexilile gear shell f<:>rce ii into an egg shape and into 
contact with the rigid outer ring gear. One rotation of the 
lobe assembly causes the two gears to displace relative to 
one another by Iwu teeth, or 2% of one revolution of the 
flexible gear. Thus the redact ion ratio of one stage is 50:1, or 
far larger than tliat obtainable with a single stage of piiuon 
gears. Furtliemiore, since maJiy teeth aie engaged, the torque 
transmitted can be substantial. Bet^ause the engagement is 
comj>liiuU. liarmonic drives exlublt little or no backiash. 
They are more expensive, but aie common in robots and 
other liigh-perfomTanee applications because they perform 
belter and reduce the total number of paits required. 

Proceedmg outward towards the hand, the moment in- 
creases, and saving weif^bl beromes more and more impor- 
tant. Every gram Srivctt tiec nines a gram of payload. Sa\ing 
bulk is of equal uuportance. The harul, showii in Fig, 1, packs 
two ser\'os for rolatmg the finger biw and changing the grip, 
all into a cozy 20 cubic inches- Since the drive train for the 
grip extends through the rofaling finger bar, commands to 
t^iese two servos musi be coorrliiutted; otherwise, rotatmg 
the finger bar wo tiki drastic^illy change the grip on the object 
heldj ^18 explaine<i t>rcvinus]y. 



The Kinematics Processor 

The kinematics i}rotes.^)r Is one of the most interesting 
blocks of a robot, and gives ai^ insight into how robots work* 
Jls input is position data received from the PC over the 
HP-IB every few^ seconds, directing the robot to move in a 
coordinated manner from the last Cartesian position to the 
next. For example, a command string might direct the robot 
to move from coordinates over a test tube rack to coordi- 
nates over a balance a meter away. .Altogether it looks like a 
complicated task, but when broken down into individual 
^teps it is easy to grasp. 

Robot Joint Space and Cartesian Space. One imt>ortanf simplifi- 
cation in understaiiduig robots is to understand the difference 
between two different c*x>rdinate spaces: the Cartesian space 
in which the task is defmed, and the robot joint coordinate 
space m wliich ORCA operates* 

It takes six coordinates to specify the position and orienta- 
tion of an object in space, hi our famihar Cartesian sj'stem^ 
these coordinates are x, y, z, yaw, pitch, and roD. ORCA is 
fixed ill yaw, so we restrict oiu- interest to the other five de- 
grees of freed om^ A sixth degree is added, however, and that 
is pinch, to control the fmgei^. In friendher tenns, we will 
refer to these six degrees of freedom as rail (x), reach (y)t 
height (z), bend, twist, and grip. 

Robot joint space Is defined as the joint positions of the 
robot that must be established to place an object in space 
witli a specified positiori ar\d orientation. ORCA has six 
movable joints, each cuntrollefl by a set^'o. Settmg each of 
these correctly will posidon an object in Cartesian space. 
The six joints represent the six degrees of fi:-eedom in robot 
joint st>ace. They are rail, shoulder, elbow, wrist, twisi. and 
grip. Note that only rail, twist, and grip are the same in bolii 
( o on i i nate systems. 

Part of the reason for belaboring these differences in coordi- 
nate systems is that tis the tasks of the robot nre divided up, 
some are distinctly easier to perform iri t Jiriesian space and 
others in robot joml spac^e. In any case, the tjansformation 
must eventually be made to the joint space coordinate system 
to control tlie robot. 




Fig. H^. Ilaniioiac <lriv«^ rHlnrliori unit. 
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Gravity-Sensing Joy Stick 

What is the most mruitive way to teach moves to a mhot? For the HP ORCA 
system, joy sticks rap fd I y became Iron? runners. Ttiey are portable, allow control 
of many degrees of freedom, and combine delicate movements with the capability 

of high speeds. 

The problem is that six degrees of freedom need to be tatiQhti rail [xi, reach |y), 
height (z}, bend, twist, and pinch, Two degrees of freedom are easy to master, 
Everyone who picks up the jov stick can intuitively fly the robot in traverse and 
reach |x and yS The question was, "What would be intuitive and affordable far 
commanding the other axes?'' Shift keys on the stick housrng are common but they 
rarely become habitual, and reisaming which one to press distracts ones attention 
away from teaching the robot 

The HP solution is to add gravity sensors to the stick box that sense its orientation 

and dynamically reassign the axes, transforming the joy stick into a teach pen- 
dant Fig. 1 shows the joy stick and the sensors, The three mutually perpendicular 
tiJt switches required to sense the six possible orientations are mounted along the 
(l-1JH-lAlUnd {1,1.11 vectors. 




Hg. 1. DRCA robot joy strck artd orientaiion-smising tilt switi:;hBs 

In use. tilting the joy stick to its right changes the stick from controlling traverse 
and reach to controlling height and reach, In other words, if the joy stick won't at 
first ber^d or move in the desired direction, reorient the box so that it wiEI. Pointing 
the stick right, left, towards the user, or even down ali have the expected result 
The only exceptions are that wnst twist and hend are cantroiled by pointing the 
stick away from the operator, and twisting the knob atop the stick always controls 
finger grip. It's a teaching system one never forgets The user moves the robot in 
Cartesian space, not robot |aint space, whjch is a tremendous simplification for 
the user. 



CoiTtrolIing the flobot. Hie llrsl st.ep ijt rrjbot control is to df»- 
llrie I he snaiglri line along wtiicli the coordinated iiiotion 
will fjcc nr. This is a matter of straightforw^aRi intei-polation 
hi Cartesian space. For example, when the robot is 4TO of 
the way to its destination, the six individual coord itiated 
degrees of freedom (x, y, z, bend, tvi^ist, grip) wiJl each be 
40% of the way to tlieir final vaJues. If die final twist of a 
pourhig operation Bt:artmg at 50 tJegrees is to be 100 flegTTees, 
for example, Itien at the 40%pohit, die instantaneous twist 
command will l>e 70 degrees. 

The second step is to compute the velocity and acceleration 
profiles so 1 fiat the robot will accelerate up to speed, tra- 
verse a distance, iiud decelerate and smootlily stop at the 
end of the ntove. Here the task is t wf>fald. One is to allow 
the MDS software (o control the speed of the ntove, 'fhe 
second is not to exceed the liardware performtutce limits of 
any robot axis. This siliiallon arises because an articulated 
robot Uke (JRCA is capable of niu<'h faster speeds in some 
directions and portions of tlie working space than in others. 
For exanipic, if the anil is fully oittst retched it can move 
vertically vciy^ rapidly, but if commi^uitled to move inwiird 
towards the torso, its speed is limited For a momr^ut as the 
elbow^ tiles to accelerate venically to infinite velocity, 'fhe 
HP ORCA system avoids such situations by limiting the 
velocity and acceleration to the lower of two nnmbersi the 
conmtand from the PC or the lijuit^ of tJte joint servos. 

The kinematics processor code is maOiematiciilly intensive 
and requires a fairly powerful 16-bit microprocessor. The 
processor has quite a mmiber of tasks to perform in addition 
to computing way^ioints along the strmght-line tr^ectory 
betw^een the robots htitial and final positions. It takes the 
processor 40 milliseconds per wa>i>omt to complete all of 
its computations aitd tasks. Thus the determination of 
w^here the robot siiould be is not continur>us at this point but 
periocUc, and the period is relat:ivcly lon^. However, tiiis is 
Just an inteiiiicchate step in the control process. The infor- 
mation is still in the wrong coordinate system and is far too 
coarse for smooth motion control of the robot. 

Immediately afier computing each coarse Cmtesian way- 
point (evciy 40 ms), the kinematics processor coit veils the 
pomt into robot joint space coordinates. The x coordinate is 
easy to tr;:msfonn sitK^e it is the same ir\ hot It spaces; the 
robot merely moves a certain mmiber of mi Ih meters down 
the rail to the new x coordinate. The same is true with grip 
conmiands to the grippen The y (in and out) a^id z (iieighi ) 
coordinates are .slightly more eoinplicated tt> tnmsfonu, and 
use trigonometry^ to compute the shoulder aitd elbow Joint 
tmgles in robot space. The wi ist joiitl is not a factor if it is 
kept horizontal; its angle bears a simple relation to the 
shoulder and elbow joints. 

In addition to transforming the waypoints from Cartesian 
space to robot Joint space, the kinematics processor also 
applies the tool offset iiaramelers, if t here are any. so that a 
test tube ctm be rotated about its lip instead of its pomt of 
support, for exanTple. The kinematics proc-essor outputs a 
joint-space vector ever>^ 40 ms and sends it to the six Jriint 
servos for furiher processing. 
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Joint Sefvos. Two wires of the four<*onduclor ORCA bus that 
snakes through the rot>ot cajT>- t^ie serial RS4S5 joint com- 
mands to the joint servos, which are embedded in the rabai 
shell. TTie other two conductors earry unregulated '^2\ power 
The data struciiu*e sent over the ORCA bus is showTi in Fig. 6. 
Each pair of joints is serviced by a microprocessor wiiieh 
strips off its commaitd from the bus at 40^ns inierv als. After 
eacli joints two-byte pofiiti<jn conuoand is sent, an idle space 
is pro\ided for the joint to send back its position and status. 

The fourth step in the robot control process takes place in 
the joint microprocessors, which further interpolate the 
40-ms inter\'al down to L25-nis position demands for the 
joint servo. V\1iat is the purpose of all dus mteipolatiiig? If 
the 40-rns j>oints were sent directly to the senos, the robot 
motion would be jerky. Yet It is unecononiical to generate 
them faster than 40 per second; that would take an unneces- 
sarily fast kinematics processor and would take up too 
much bus comnitmieation time. There is an easier w^ay to get 
the fine incremei^ts f o *^eiui lo the jomt ser\^os to ensure 
srncjoth motion. TJiis inteiijoiation step is the task of the 
joint n>icrocomputers. which divide the motion dov^Tt into 
L25-iits mterv^als. This interpolation produces smooth, non- 
jerk>' robot motion by keeping the step noise at a frequency 
well beyond the passband of the robot servos. 

This is a particularly easy interpolation to accomplish, since 
the number of steps chosen, 32, is a power of two. Interpola- 
tion then consists of subtracting successive positions, divid- 
ing the difference by 32 (a right-sliift of a binary number by 
5 bits) J and sticcessively adding that quotient mto an accu- 
mulator mitiatized to the starting servo demand position. 

A conseqtience of this design exi)edient is that the robot 
actually moves m slight scallops, 40 ms lon^, since a straight 
Une in robot joint space is curved in Cartesian space. How- 
ever, rliese deviations are on the order of thousandths of an 
inch iind are insignificant . 

The rem anting task performed by the Joint microprocessors 
is to close I be digital serv-os at each joint. These seivos use 
incremental encoders, dc motois, and pulse-widtlvniodtLtatet! 
ampliners— tec^hnology boiTowed Ixom HP plotters.^ Briefly, 
each joint demand position is first subtracted from the actual 



position of tliat joint to generate a position error \'alue. The 
servo motor is then commanded to move at a velocity pro- 
portional to that position error, with the velocitj' and posi- 
tion of the joint servo motor being derived from the incre- 
mental encoder Since each joint position is fed back to the 
PC, the control software knows if the robot has bumped into 
anjthingj and can also employ integral control to correct 
small errors such as sag of the ami caused by the influence 
of gravity 

A new HP technology introduced in the HP ORCA system is 
distal absolute position encoding (see ** Absolute Digital 
Encoder.*' page 14) at each of the m^or joints. Its purpose is 
to allow the mechanism to ascertain its position when first 
powered up. 

Application Development Environment 

Although clearly rhe most conspicuous element, tlie robot is 
but a piece of a total autoniation system that also iinolves 
controlling and collectijig data from anal>1lcal instntments 
and common laboratory' fle\ices, such as pH meters and 
balances. The HP Met bods Deveiojinient Software (MDiS), 
wTitten to address this need, provides a cieveiopnienl envi- 
ronment for creating aut omation systems with laboratory 
robotics. MDS runs under Microsoft Windows on an HP 
Vectra or other PC-compatible computer. T!\i.s choice was 
based on tisers' preferences for a PC-based sysieni, coinpaii- 
bilitj^ with HP ChemStations, and the features tliat NOt^rosoft 
Wmdows provides for a multitasking gi-ajihical usei' interface. 

The targeted customer for MDS is a laboratory robotics ap- 
phcation developer, typically an analjlical chemist with 
instrumentation and BASIC progi"amming experience. Tliese 
developers create applications thai a tei Imitian tuns and 
monitors. Robotics programming has tr> he presentefl in a 
conceptually simple format that makes it easy for the chem- 
ist to create tasks, which can then be combined to form an 
application. 

Again, the differences bel ween the use of a robot in the lab- 
oratoiy ami I be miuiufactunjig en\dronment were considered. 
Wherea.s a manufacturing robot is typic^illy programmed to 
rei>eat a small set of tasks in a world that can often be 
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defined with mfomiation from CAD drawings, a laboratoi'y 
robot is iisiHl to ])eifomi a wide variety of laslts in a wt irlti 
where ver>' little predefined knowledge is available. The 
laboratory robot mnst be taught how to interact with test 
tubes, vials, racks, balances, and other instniments. 

Teaching a robot all of the individnal positions and irayecto- 
ries it must follow for every step in a lal>oratory application 
would be very time-t:ons\miing and tedious. The teaching 



process can be greatly simplified by providing a mechanism 
for teaching small tuanipulations instead of Lndi\'idual posi- 
tions, Tliese small man ii^ulat ions caii be used (and, most 
important, reused) as building blocks. This idea led to the 
concept of a robot motion. A motion in its simplest form is a 
sequence of robot j)ositions. The motion is taught interac- 
tively using a special motion editor and the robol teach pen- 
dant. The motion is givett a descriptive name, wluch is used 
in a progrmn to have the robot execute, or move through, 



Absolute Digital Encoder 

The HP ORG A mbot uses dEgitai servos with incrementaf encoders, which need to 
be initialized when the robot is first turned on. Manydigual servo products, such 
as plotters and impact printers, can ln^tiaiize themselves by traversing to the ends 
of each axis, For many other appltcations. such as, for example, car seats with 
memory, robots, or machine tools, this expedient is either impractical or risky, One 
solution is to add a potentiometer, but this carnes a cost, complicates the wiring, 
and is incompatible with leadscrew dnves 

The encoder developed far the HP Of^CA system is a small package less than 1 cm 
thick, which fits at the rear of the moter ehead of the incremental encoder It uses 
a system of permuting gears, whose phases are measured to ascertain motor 
revotuiion number Fig. 1 shows the encoder mounted to a servo motor, with its 
housing cut away to show the gears. 

In practice, a center gear and a transfer gear with 23 teeth combine to drive plastic 
sateliite gears with 24 and ?5 teeth. In operation, as the motor turns, the satellite 
gears graduallv fall farther and farther behind the drive gear. Thus, as the motor 
continues to spin, the gears go through a iengthy tist of combinations of relative 
angles. This effect is shown in Fig 2 for the first two rotations, an arbitrarily large 
number of rotations, and rotatton number 599 where the cycte is nearing comple- 
tion. If the gears have numbers of teeth that do not have commnn multiples, then 
the cycle is unique and does not repeat umif 24x25 = 600 revoiuttens have occurred. 
Since this is more revolutions than ORCA requires to traverse any axis, any gear 
orientation corresponds to one unique revolution nomber and therefore one unique 
robot aj(is position. The gear phases are measured by shining fight from LEDs 
through si its in the gears and onto optosensors 

In use, the signals from both the absolute and the incromentsi encoders are routed 

via a ribbon cabfe to each corresponding joint microcontroller, where a simple 
algorithm based on modulo amhmetic is used to convert the phase measurements 
into a revolution number When each servo wakes up, its joint motor rotates one 
revolution and stops. This produces a slight motion, and m milliseconds the mjcro- 
contfoller knows the absolute position. HP is interested in exploring commercial 
applications for this or binary versions of this component and technology 
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the sequence of positions. In MDS, the program is called a 
procedure. Procedures are used as building blocks to connect 
robot actions witii control of other devices and instruments 
into hi|S^er-level lasks. Procedures can call other procedures, 
much like a subroutine call in BASIC. 

The concept of a motion was generalized to be an abstract 
execution object, which led us to consider other types of 
objects that could be provided to simplify robotics pro- 
gramming. These types include: 

• Tool DeSnes the endpomt of the robot arm. 

• Fnime. Defines a frame of reference for a motion. 

• Motion. A sequence of robot positions. 

• Rack. A rectihnear array or positions (similar to a pallet). 

• Syrconfig. A configuration for a syringe pump dispenser 

• Procedure. The basic piogranuuing miit. 

• Device. A configuration for an RS-2:32 or IIP-IB device. 

The metaphor used to create and store these objects is that 
of entries in a dictionaiTr'. Motions, racks , tools, frames, syr- 
configs. deiices, mid procedures are all types of entjies that 
can be created. An entry is an execution object, and a dictio- 
nary is a file that holds the entiy objects. Users create and 
name entries, arid save them in a dictionary. Each entry type 
has Its own s^jecial editor, or form, for defining or teaching 
the entry. E!ntries can be used as commands (motions and 
racks) J or as rnoclifiers of entry commands (tools and 
frames). 

For example J the following j>rocedure slate nt en L will exe- 
cute a motion PickLfpOispenserNazzle using a tool offset dell lied 
by the tool No^zleGripper and re-ferenced to a Irame MooleStand: 

PickllpQispenserNozzfe WITH NozzleGrlpper AT NozzleStand 

Tile I'ranie tmd tool that a motion uses can also be attached 
(x:) llie motion from withui the motion editor, and may provide 
tie faults for the motion to use when it is executed. Tlie use 
of long (^31 -character) names and the conunand modifiers 



WITH and AT provide a ven,^ natural-language-hke look to pro- 
cedure statements for robot control and help the proceditre 
code to be self-documenting. The use of longer names is 
simplified and encouraged by providing a variety of selec- 
tion, copy, and paste features in the user interface, whicli 
reduces typing and progranuiiing errors that arise from 
tjTJing mistakes. 

MDS allows two dictionaries for editing and execution of 
entries: a user dictionary and a master dictionary; When an 
entr>' is referenced in a procedure statement » the user dic- 
tionary is searched first, and allows redefining entries tliat 
are in the master djctionarj. Although developers are free 
to choose Tiieir own guideiuies, the master dictionary is 
recommended for saving entries that are to be used across 
multiple applications and the user dictionary is generally 
application-specific. 

The user interface for selecting entri^ to edit and for general 
browsing of the dictionaries is the MDS tlictionaiy manager 
window (see Fig. 7). Tliis window is the main user mterface 
to MDSt and provides access to administration utilities, dic- 
tionaty and entry manipidation. and selection of various 
views for the entt>' listings. Double chcking on an entry 
name presents ati entry information dialog box, which ui 
turn allows access to editing, execution, or printing of the 
entiy Keystroke accelerators at e provitled for quick access 
to common functions, such as editing and execution. 

The dictionaiy manager also provides a command hne, with 
history, for execution of commands. MDS supports the con- 
cept of a live command line, from which a user can execute 
anything at any time. Tlie new execution preempts current 
execurion. Tliis feature is usetl most often to access or 
change the vakie of a variable quickly, and to t^xecute proce- 
dures to correct problems when the application is ijaused 
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"^ ► MDS Message Links 

Variables thai are defmed exist until Ihey are explicitly re- 
iiioved. These feaitues give MDS ai; interactive feel, atid 
allow ttve creation aiid testing of an application in ternis of 
small units. 

The other main user mterface window is the MDS monitor 
(see Fig. 7), which shows display output from procedure 
statements and provides execution control and debugging 
facilities. Debugging facihties include execution stepping, 
tracing, and logging display output and errors to lug files. A 
variable-watcti window^ which can be used to monitor the 
values of variables as they chaJige, is also provided via the 
MDS monitor menu. 

Tlie procediu^e editor is the other most conmtonly used ele- 
ment for developuig an application. Each procedure is edited 
within its own window. Multiple edit sessions are possible, 
and text can be copied and pasted between then!. The pro- 
cedure editor also allows execution of the entire procedure 
or any highlighted texl. Ttiis feature atlowy qitick and simple 
testing of statements and procedures. The procedure editor 
also provides direct access to other types of entry editors, 
mchiding other procedures- For example, the user need only 
double click with the nunise lo highhghl Ute name of a pro- 
cedure, or other entry, and press Ctrl+E to access the editiM^ 
for drat entiy. The procedure editor's features enctnnage the 
use of smatl procedm-es that can be easily tested to become 
building blocks for higher-level procedures and enhance the 
interactive feel of MDS. 

MDS Architect ure 

hi addition to supporting tJie features described hi the pi-e- 
vioiis section, MDS is designed for extensilulity. Because of 
the wide-ranging nature of laboratory robotics, iuul because 
it is a developing field, the types of instruments and objects 



Fig. U. MDS arrhi lecture. 

with which the robot must interface cannot be predefined in 
the software. Thus the software has to he both configurable 
and piecewise upgradable. The software also has to support 
multitasking of exec tit ion and simultaneous editing and pro- 
gramming rlui'ing execution. Tliese requirements suggest a 
modular design, with several programs that interact with a 
defined protocol. Fig. 8 shows the MDS architecture. 

The design of MDS is based on a core system that can be 
enhanced by the addition of software modules. It is imple- 
mented as several Windows progrmns that communicate 
with a set of MDS n\essageSj and a set of Window^s dynamic 
link libraries that provide the basic "glue" for the architec- 
ture. In Window^s, the use of dynamic Imk hbraries allows 
sharing of connnon code and shaiinj? of data betw^een pro- 
grams. MDS takes advantage of djTiamic link libraries for 
both of these purposes. Since Windows itsetf is implemented 
as several dynamic link libraries, the various programs that 
make up MDS do not have to include code for the windowuig 
interface. Run-time memory requirements are Mso mLnhiuzed 
by taking advantage of Wmdows meniory management facil- 
ities that allow code segments aittl data lo be marked as 
load-on-call and discardable. 

An important design rule for MDS w^as that no data structure 
defiiiitions could be shared between the programs and dy- 
namic Imk hbraries that make up MDS. This ruJe allows MDS 
to be tiiily modularized so that parts of MDS can be modi- 
fied without affectmg or requiring changes to other parts. A 
direct benefit was that it enabled the core system to be de- 
veloped in Palo ^\lto while the rtibot and dispenser modules 
were developed at the AvondaJe site. 3000 miles away. 
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Instead of data stmctories being shared, a set of data objects 
were defined aiid supported with calls to access their prop- 
erties. These data objects are supported within d>Tianiic link 
libraries, which provide the fimction call access, and which 
**o%Ti' tlie data and allow it to be shared. For example, the 
MDSDICT dynamic link iibrar>^ suppoits the dictionaiy and 
entiy objects, the MDSCFG dynainic iink hbrar>^ siipports 
the configuration and module objects, and rhe MDSCPUB 
djTianiic link librar>' supports objects usee! for exectition. 
The use of ihe d>Tianiic link library" s local heap for aliocating 
the objects compeanaies for the performance penaJty of the 
overhead of the calls to access the object data. Handles to 
the objects are passed among the MDS programs using MDS 
messages, which specify ait action to take with the object 

Certain objects and their corresponding calls and messages 
are considered "core-only" property. Modules can only ac- 
cess information in these objects using an intermediary ob- 
ject tJiat can be properly shared with modules. For example, 
the cntrj^ imd dictionai^' objec ts are core-only, so an entry 
edit block object is used to create and e^lit an eniry object 
and is ac^cessible by modules. Even in this case, though, not 
aU of the objects properties— its correspoiKiing entr>^ and 
dictionary for exiunple — are accessible by modules. Tliese 
properties can only be set by a part of the core (the module 
manager or browser in this case). 

MDS modules extend the functiuntdity of MDS by providing 
support for new entr>' types cuid commantis. Currently, there 
are three modules available: the MDS system module, the 
OKCA robot module, and a dispenser module that supports 
die MP 1243A syringe pun\p dLsjiensen The system module is 
different from the other modules in tliat it is an integral piu1 
of the MDS core, wiiile tiie other modules can be optionally 
configured to run as part of MDS. Moflules are responsible 
for the control of their respective harxlware iUM\ entry editors, 
and for execution of tiie commands iind fvmt1it>jis that they 
register with MDS. Although the current ntodules all siippoil 
hardware, modutrs can be wTitten simply to atid eonunands 
orother function ah ty to MDS, such as interfacing with 
another software package. 

MDS Core. The MDS core system consists of tlie niodule 
m^inager MDS. EXE, the browser MDStTSER.EXE, and tlie 
executive MDSEXEC.EXE (see Fig. 8). The executive in turn 
supports the MDS command prcjcessor MDSCREXE as a sep- 
arate progratn ihat il manages. Three dynamic hnk htjr^uies, 
MDSC FCiJJLt,, MDSDItrr.DIi^ and MDSCPUB.DLL, complete 
the MDS core. 

The modtile manager Is the main MDS program. Its window 
appears only momentarily to show booting information, an(J 
is then hidden. The module marvager acts as the main gate- 
way ff >r all MDS messages, h is resi)onsit>le for maintaining 
the c(Hingu ration of MDS rnotinles (via MDSCFG.DLL) and 
dictitjnaries and entries (via MDSDK^TDLL). Wlmi MDS 
boots, the module manager reads configuration information 
from the MDS.lNl tile, and executes the module programs 
tiiat are to be activated. Motliiles flyrvamically register tlieir 
entry iype and keyword iiifunuittion witli the module man- 
ager at hoot time, Tlie niodiile matiagcr also supports dia- 
logs for iiiijditying tlu' configuration, and for creating atid 
Siiving entries. 



The bn>wser is the main user mterface for MDS. Its window 
title is MDS Diction a ry^ Manager, becaase that is how it appears 
to function to Ihe user. hitemaHi^ howevTr^ it is not die dic- 
tionary^ manager; it senes only as tlie user interface to the 
niodule manager which is responsible for maintaining dic- 
tionaries. This distinction between hoiv a user views MDS 
and hovv MDS Is implemented internally was important for 
maintaining a consistent internal design. The browser win- 
dow provides the command tine and a Usting of entries de- 
fined in the selected dicUDnaries. The browser also supports 
the sen er portion of Windows dynamic data exchange 
(DDE) for MDS. 

The executive provides the other i^indow into MDS, the MDS 
MoHFtor window, which displays output from procetlure PRINT 
statemerUs. Ttie executive also manages the MDS command 
processor atid provides the user interface for execution 
control and debugging facilities. 

The MDS conunand processor is responsible for procedure 
and text execution. All execution begins as tex1 execution 
(from the command hne, a procedure editor, or remote DDE 
execution), wiiich is parsed ant! executed the same as a pro- 
cedure. The syntax for the MDS procedure language is 
btised on the HP ChemStation macro language (which is 
BASlC-like) with a number of enhancements. 

.\mong the enhancements are support, for the MDS entr>^ 
concept and a PARAtLEt coinmajut The PABALLEt command 
allows procedures to be exetnj ted in [jarallel, shaiing the 
same global symbol table aiul «Jictionaries. A set of com- 
mands for synchronization of parallel execution is also pro- 
vidcf 1. Tills multitasking feature is used to increase the o%^er' 
all throughput of sm apphcation. For example, a jjrocedtire 
that lares a balance can be done in parallel with mtother 
procedure that uses the robot to get a beaker tbr weighing. 
Wtien a PARA t LEI command is executed, a new nistance of 
the MDS coninumd processor is nm. Because Windows 
shares vodv seguK^nts for multiple instances of the same 
[jroj^rani, the command executes c|mckly, and the detnands 
on fuetnory arc linuteil to the additional data segment for 
ttie new instance. 

The MDS command processor parses and executes eac:h line 
of a t>rocedure at nui time. An e^xecution block object is 
used to pass execu I it ju inronuation between the conunand 
processor and the iiKjdules during execution. Parameters to 
module c<:>mniands are preevatuated for the module and 
passed on a shaied stack object, whose handle is part of the 
execution block object. 

An important i>art of aufonmtjon Is the ability to det(*ct and 
recover from error conditirMis. MDS supjjorts the ON ERROR 
statement, which specifies iin error handling procediue to 
call. Through the use of a RESUME statement, the error han- 
dler can prot>agate the error back (RESUME EXIT), tlx ajid 
retiy the staiernem (RESUME RETRY), skiji the statement 
(RESUME NEXT), or have the user decide (RESUIVIE ALERTJ. The 
automatic error handling can be disabled, so that an error 
dialog bfjx is always i>reset^ted to allow the user to decide 
what action to take. The user can execute new procedures 
to fix the (utibleni iuiti retoni the application to a (^ontinua- 
ble state. This feature is paniculiuiy helpful during develop- 
ment of the applit^ation, mid reduces the neetl to abon an^J 
restart an appliration wlien something goes wron^, 
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MDS System Module. The MDS system module provides sup- 
port for procedures and devices. It is a *'core-smart** module 
in thai iJ uses certain calls jmd messages thai are considered 
core -only. For Litis reason, it is nsiially thouglit of as part of 
the core sysleui Also, il is nof a Inie rnoduk\ in that il only 
provides for the creation and editing of procedures and de- 
vices. Procedure execution is h^uidled by the MDS command 
processoi; whicli Ls maintained l>y the MDS executive. Device 
entiles are nse<l in [n-oceduies, so tlieii execution is also 
l\aitciled by the MDS conmtand processor. 

Dispenser Module, Liquid handlinj^ is important in many labo- 
raloo' robc>lics api>lications. Solittions nuisi bv prepared, 
fdlered, anti extracted. The use of liquid tUspensing iit com- 
bination with a robot and a balance allows lite gravimetric 
prejiaiation of solutions, eliminating errors lliat often occur 
with the more traditional volumetric methods. 

The disijeiiser nuxhile supports the syrconfig entry iyp^\ and 
control of tlie HJ' G I243A syringe pump dispenser A syrcon- 
fig specifies which syringe to use, the syringe size, and the 
dispense speeds. An AutoFill feature allows the user to set 
levels at whicii a syriitge will automatically retllL When en- 
abled, this feature eliniiiiates the rieeil for the application to 
keep track of syringe levels, tlius reducing procedm^e cwiiiig. 
The dispenser module also registers a set of commands that 
are used wdth the syrconflg entry to dispense ajid fill liqvuds. 
The dispenser module is implemented as a single program. 

For example, the following statement wHi dispense 10 ml of 
liquid using the sjTinge specified within the syrconfig Buffer: 

DISPENSE 10 ML Buffer 

With AutoFill enabled within the Buffer syrconfig entry, the 
syringe will fill and empty until It) ml are dispetised, using 
tlie volume setting in the enrty as a guide. During the fill '<md 
empty cycles, a valve is automatically switched so tl^at fill- 
ing is done from a resen oir and emptying is done out 
through a nozzle. 



Robot Module. The robot module supports the HP G1203A 
ORCA robot. Tlie robot motiule provides the tool frame, 
motion, and rack entr>^ tyi:^es, and a set uf ccjitirnands tind 
ftinctions for explici! control of the robot arm. The main 
robot window presents current robot position and status 
infonnation, tmd pro\ides access to calibration iutd entry 
edits (see Fig. 9 J. Muliiple editors can be opened at any 
time, and positions catt be copied and pasted. 

All of the robot entry editors except for the tool editor are 
used interactively wiih the robot and its teach pendant. The 
user ctm idso manually enter position infonnation. For ex- 
ample, the motion ecUtor presents a fonii for recording a 
sequence of positions. Pressing the remote t^each pendant 
Epter key automatically records the current robot location as 
the next position in the motion. The motion editor allows 
setting tV>rce (grip) and torque (twist), as well as speed for 
indi%idual steps in the motion. Tliese parameters, along witJi 
a reference frame and tool offset, are called motion attri- 
butes. Another attribute, Donl Change, can be applied to iudi- 
\idual axis values, mid indicates that the axis value does not 
change for that position, no matter what value might have 
been taught. ()nce tatight, positions in a motion can be 
rearranged or copied betw^een motions, A motion that is 
used tf> pick up m\ object can easily be reversed and saved 
as a motion that replaces the object, 

A rack is defined by teaching two comer locations and an 
act ess location, and liy enterir^g the number of rows and 
coltmms for the rack in the rack editor Or\ce defined, tiie 
desired rack location, or index, is specified as a parameter 
to the rack name in die conunmid to mov-e tlie rt)bor to that 
rack access location. By teaching a rack wltJi resjieet to a 
three-point frame, the rack can be accessed in virtually any 
orientation, with the robot bend and twist axes chaiiging to 
refiecl the new access angle. A htmd-reference mo(ie of 
teaching, by which the bend is locked at im angle perpendic- 
ular (or parallel) to the rack surface, greatly simpltfies 
teaching access to tilted racks and centrifuges. 
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The robot coordinate svbtcm is presented as a Cartesian sys- 
tem witji additioiial t>end, twist, and grip axes. The robot 
module pro\ides the frame and tool offset transformations 
for motion and rack pc^tions. The conversion to joini \*alues 
and the straigJil-llne tr^ectories are all computed In the robot 
kinematics processor. W^Tien executing a molion, for example, 
the rotjot module apphes rJie frame and tt^cil oflTsets to each 
position in the motions, convertii^g these vaines into absolute 
positions to send to tiie robot kinentatics processor. 

Use of Other Laboratory Eqiupment 

A critical reqiiiretnent for the MUS software is that it be able 
to support conunon lai>oratoiy de\1ces tlirough standard 
interfaces, MDS supports control of HF-IB (IEEE 488) and 
RS-232 (COM) interfaces using the de%ice entr>^ type and 
procedures writteji to use the devices. The device entry type 
provides a simple form for iissigning the address. COM port 
parameters, ajid buffer si/.es. The MDS procedure language 
supports using the device entr>' nanie in place of a file name 
hi the BASIC-like OPEN statement. This allows the BASIC 
examples mcluded with most manufacturers' instruments to 
be easily incorporated into MDS, 

Dynamic Data Exchange {DDE). Early m the project wc emi- 
sioiied MDS as being the m^iister controller of the robotics 
bench. As the project progressed, it rapitUy became e\idenl 
ihat MDS must also be capable of being controlled by other 
applications iuul nuist be able to exchange data with other 
applications. High on (he list of other applii aliens \\{^v the 
UP family of ChemStation products and sdti waie piovjded 
by other manufacturers for mstnunents that HP does not 
provide. 

Windows d>Tianiic data exchange (DDE) was cliosen as the 
mechanism for the control iini] exchange of data, DDE aj- 
lows Windows applications to <'ontrol and pass data using a 
client/server model. MDS supports DDE in both client and 
server modes- The DDE chent support is handled by a set of 
commands that allow developers to add DDE lo their aiipli- 
cation at a ver> high level MDS handles all of the I (.>w- level 
Cietails of the prottn^ol. The DDE server suppoil is handled 
by the MDS browser iuul con utumd processor, and allows 
remote execution of any block of text that follows MDS 
command! s>iitax. All MDS variables are accessible via DDEj 
both for setting and requesting values. In additioii, MDS vari- 
ables can be put on advise^ or "iir Jt-linked," which means 
that the client application is notified whenever the variable's 
value is changed. 

By supporting DDE^ MDS is able to interact with a wide vari- 
ety of software thai runs under Window^s. Featmes that MDS 
lacks, such as datal>ase management and report processing, 
caji be pro\ided usiitg software designed for that purpose, 
using DDE as the ci^Jinection with MDS. Anotlier example is 
die use of HP ChemStation softw^are with MDS. Using DDE, 



MDS is able to instruct the ChemStation to load and run 
methods for samples that the robot has prepared and placed 
in the chromatograph s iryector. The use of DDE to integrate 
MDS with other Windows applications provides a rtew level 
of systems automation for the anal>tical laborator>'. 

Conclusion 

The IIP ORCA hardware and software provide a robotics 

system that is easily adapted to the needs and requirements 
of the analytical laboratory. The use of a gravily-sensing 
teach pendant, in coi\junction with a graphical user inter- 
face, provides an intuitive and simple mear\s for program- 
ming the robot. Supporting both client and server dynamic 
data exchange, the HP OHCA system can be fully integrated 
into the information flow as weh as the sample flow of the 
analytical iaboratorj^ Applications outside the analyrical 
laboratorj' are also easily found (see ""The HP ORCA System 
Outside the .^alyiical l^aboraioty;" page ^). 
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HP OpenODB: An Object-Oriented 
Database Management System for 
Commercial Applications 

The functionality of object-oriented technology and basic relational 
database features such as access control, recovery, and a query language 
are provided in HP OpenODB. 

by Rafiul Ahail and T\iHiig Cheng 



HP OpenODB is an advanced object-oriented database 
management system (ODBMS) that is designed to support 
complex commercial applications. Commercial applications 
reqnire support for Uirge mmibers of conrnrrf^nt users, many 
siiort tnirisactions, security iuid authorization prf)cedures, 
bigii availability of information access to other databases, 
and higli integrity. IIP OpenODB is a hybrid ODBMS that 
f^mibines several years of research and development on a 
fiataliase nl>jef'1 manager with a derade of investment in 
relational datalia-se lechtiology. This powerful ( ombinalion 
brings die two pieces that make up an object together in an 
ODBMS. It al.so enables a smooUi evolution from» and coex- 
istence with, a relational database management sysf.etn 
(RDBMS). 

In the currenl release, all of HP OpenODB's stored data is 
managed by AbLBASE/SQL whirli is HPs ANSI standard 
relational database aJMi is tuned lo bv the fastest RDBMS on 
HP platfonns, ll\e HP OpenODB object model is imple- 
menled by an object manager which jnovides unliralted 
nserdetined types of information. HP Oi>enODB is designed 
to port easily to other RDBMSs. 

HP OpenODB is welUsuited for applications with one or 
more of the following characteristics: 

• Complex and varied data stmctures 

• Various data formats 

• Access to data stored in different systems 

• Constantly c hanging environment 

• Multimedia storage iind manipulation 

• Multhiser ac cess to infoiTiia t i < n\ . • 

This article will describe the features and the software 
architecture of C)i>enO!)B and the object model provided in 
OpenODB. 

Product Features 

OpenODB's oh] ert oriented features help reduce develop- 
ment and maintenance costs liy allowing the developer lo 
model bus uiess problems more irUui lively. These feat tires 
can be di\ided into the following categories: 

• Tools that ailow' developers to use object-oriented mocieling 
techniques to build a database 



• Progranuuatic capabilities that allow storing code in the 
database and interfacing to external functions that support 
access to external data and preexisting applicatitms 

• Run-time jjerformance features such as late bmding ant I 
schema modification 

• Access cfjntrol and data integrity features. 

Object-Oriented Modeling 

The features in this category allow users to use OpenODB 
objects, ty)>es. and functions to model the attributes, rela- 
tionship's, and beha\ior of things m the real world. 

Object Identity, Bach object storetl in OpenODB has a system- 
provided unique handle called an object identifier (OID). 
01 Ds reduce duplication of information and relieve the de- 
veloper of the iiee<^l to create unique keys to identify stored 
infonnatioii in tJie database. 

Complex Objects. Complex objects can he const met ed from 
simpler objects. C Complex fibjects relieve applicalion code of 
the need to tnanage the relationships between simple objects. 

Referential Integrity. Since OpenODB know^s about the rela- 
tionships between object^s. it can maiiage refereiTlial irUeg- 
rity. With this feature, if ol:>jects referenced by other oi>jects 
are deletetl tl\e system removes ail dependencies. The user 
can specify whether or not to ciiscade changes or just to 
delete the immediate dependetYcy. For instance^ if manager 
A1 supenises employees prohn^ Mar>', and -Toe, and employee 
Joe is deleted, function call NamejManages[:AI}) will return just 
John ami M^u>^ The result is a simplitlefl database schema 
and simphried apijlicaiion code that can be developed more 
quickly since the user does not need to manage referential 
integrity explicitly. 

User- Defined Data Types. 1 Isers can construct user-defmed 
data types in (J|)eaOI)B rather than having to do it in the 
application code. 

Type Hierarchy, T^pes cim he organized in a hierarchy. This 
hierarchy of types and related fimctions allo%vs users to mini- 
mize the tnuislat.ion from a business model to an OpenODB 
schema. The hierarchy also enal>les a t>pe to inherit func- 
tions detined on paients, eliminating dujilication of functions. 
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Mufti pie InheritariDe^ F\inct3ons defined on a type can be 
inherited b^^ one or more subtypes. By mheritmg rather than 
redefinmg functions. de%'eIopers cao easiJy extend the func' 
tionality of an appliralion by reusing existing functions. 

Overloaded Functions, Several functions can have the same 
name \^1th different implenienrations. Jji an appiication, ail 
thai is needed to do is to call a function (e.g„ SaEary), r)pen- 
ODB ^iii detenu ine which code (salar>'' for employee or 
salary for manager) to execute based ui>on the parameter 
passed at run time. As a resuit, applieation code is simplified 
since tl\e logic for deiemiining which fimction to execute is 
in OpenODB. 

Dynamic Typing, An object s tyiies can be dynamically 
chimgetl ^\^thout having to destroy and recreate the object. 
This is possible because an object can belong to more than 
one t>pe. 

EncapsulatEOif. OpenODB supports the combination of data 
and iiser-detmed fund ions- Since OpenODB only allows 
access to data tlunngh these functions, an application is 
protecied from changes to the function implementation 
and the user has control over how to access infomiation 
in OpenODB. Encapsulation allows modification of the 
function body without chaiigiitg application code. 

Programmatic Features 

Procedural language. OpenODB provides the language 
OSQL (Oljject-Oriented SQL), which is based on SQL. OSQL 
includes programming Dow statemenLs, includitig IFyTHEN/ 
ELSE, FOR, ajtd WHILE, This procedural language allow^s Open- 
ODB functions to be qmit? complex, simplifying application 
code. Also, application code can be moved into the data- 
ba.se, allowing applicMtiuns to share co€le and get all of the 
benefits of sharing data. The code is tightly coupled wiih an 
object type, and OpenODB tnana^es the integrity of the code 
and its associated tyt^f"- T^^i^ ^^ <>uc cjf the features that dis- 
tinguishes OpenODB ftoui uifjre mature tlatab:ise ai'clulec- 
tures in which all of the application code is located in the 
ayipliratifjn (see Fig. 1 ), 

External Functions, losing extenid runctioiis, distributed data 
and code stored outside of OpenODB can be accessed, re- 
gardless of data foniiat or local ion, Tliis simplified \iew of 
an enterjjrise allows pr<igiauuners lo devclo[i complex sip- 
jilicalions that integrate existing <lala ;md ap]jIications more 
easily. For instance, a programuier can tlevclop ^in OpenODB 



application that accesses data stored in other databases 
(e.g.. ALLBASEySQI^ Turbolmage. or DB2) as well as data in 
flat files. OpenODB acts as an integrator so that an applica- 
tion just nee<is to know OSQL, OSQL statements can call 
functions thai access data and encapsulate code stored 
outside of OpenODB. 

Run-time Features 

Late Binding. OpenOLJB supports ftinctions that are resolved 
at nut time. Late binding allows more flexibUitj^ in apphca- 
tion development and gjv^es the full pow er of overloaded 
ftinctions as described above. Lite binding also shields user 
applications from changes? to functions since these changes 
can be tnade online and the new fimction definition resolved 
at run time. 

Dynamic Schema Modification. New functions and t^pes in 
OpenODB can be created at run time. Users can also change 
the implementation of functions without ha\ing to recompile 
application.^. 

Performance. To improve nin-time performance, functions 
cai^ be compiled ahead of time. .-\iso, related functions can 
be stored close to each other (clustered) to optimize 
performance. 

Access Control and Data Integrity 

High AvaiEebility* OpenODB maximizes the availability of 

uiformatioii l)y providing: 

• Dual logging to ensure the integrity of the log file 

• Database replication on other systems so that more users 
can effectively access the same infonnation and applica- 
tions can quickly swilcb over to another system in case of 
an unscheduled shutdown 

• Automatic switch to a second log file if the origitial log file 
is damaged or becomes full 

• Dynmnic file expansion to expand the size of the OpenODB 
rde system if it becomes full 

• Online backup of the database, which backs up the database 
w^bile it is being accessed. 

Multiuser Concurrency Control. OpenODB is designed to 
sut>porl hundretls of usits accessing the same iufonnation 
winle jTuaraiUeeiu^ Ihe itucgrity of that information. 

Access Methods on Stored Data* Indexes are automatically 
defined on object ideutillcr-s (OlDs) when types and ftinctions 
are create^l. These indexes help provide quick access to 
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infonnation -store<i in the Opt^nODB database management 
sysleni. Users can also define indexes. 

AuthdrizatJon. Access tx> OpenODB is controlled at the data- 
base and fuiH tioii levels ariti is based on aiithori 'nation level 
(individiiaJ or j^oiip). Authorization statements pro%^ide a 
flexible way in controJ access to tyi:>es and functions in 
OpenODB. 

Persistent Data and Code. OpenODB allows the storage of 
data a.s well ci-s ( udc bel ween application sessions. 

Recovery. OpenODB uses the robust logging and recovery 
facilities of the ALLBASE RDBMS. In case of a failure, 
OpenODB can handle roiJback or rollfoi^'ard recovery to a 
particular time, using the log file to recreate saved work. 

Transaction Management. OpenODB ensures the logical and 
physical integrity of the database by giving the user com- 
plete control over the unit of work to be performed within a 
single transaction. Wilb this conirol, a transaction can be 
saved or rolled back (temporar>' w^ork thrown away) to any 
point in the txausaction, 

Muhimedia. OpenODB allows the storage and integration of 
large, unformatted data in binary format. Some examples 
include gra]3bics, images, or voice data. I Tsers can also de- 
fuie functions in OpenODB to manipulate this multimedia 
intortualion. For example, Lhe iLser can store a picture as 
well as the fujiction to display the picture. 

Product Structure 

OpenODB uses a client/servTr ai'cbitecture, enabling the 
user to use available computer powder effectively. Tlie OSQL 
interface and a graphical brow^ser are located on the client 
side, and an object manager with a relational data storage 
engine and an external function interface are located on the 
server (see Fig. 2). 
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TTie user can write OpenODB appUcations usmg any language 
ihai links m\h die progianmung laiiguage including COBOL, 
FORTRAN, Pascat, Ada, aiui C++, Any fourth-generation 
language (40 LJ or CASK tool that generates C code will in- 
teract wi!h OpenODB. Application development can also be 
made easier by using tools that generate user interface code 
(e.g., OSF/Motifj in an X- Windows environment, 

A software developer uses OSQL as an object definition, 
manipulation, and ad hoc qneiy^ language that mterfaces with 
the OpenODB server OSQL can be used either interactively 
or from a program- We chose an evolutional^ approach for 
developing OSQL hy usin|? ANSI standaj-d SQL commands 
where possible and adding the full power of objects. 

The graphical browser tool allows a developer to explore 
the structure (schema) of the database and its contents. Tiie 
graphical browser is designed to increase the speed of appli- 
cation development by making it easier to reuse code stored 
in OpenODB. 

The object manager supports all of the object-oriented fea- 
tures. This includes complex objects (objects that contain 
objects), dynamic schema modification, dynamic typing and 
multiple inheritance, encapsulation, late binding, object 
identity, overloaded functions, tjqje hierarchy, and unlimited 
user-defined types. 

T^te HP ALLBASE /SQL relaliona] database provides the 
data storage and fij^iiamic schema maiTij>u]ation capabilit ies. 
These include authorization (security), declarative queries, 
high availabihty, nuiltimedia support, multiuser conciurency 
support (e.g., graphics, images, voice), recovery, referential 
integrity; and trtmsaction management. HP j\LLr3ASE/SQL is 
transparent to the application developer and end user. 

In keeping with an evolutionary approach, we recognized 
the need to access data and applications that alr€^ady exist 
in a company's network. It is important to provide a devel- 
oper access to this infonuation regardless of wiiich vendor's 
system it is stored on and regardless of its foruTat, A gate- 
way approach was considered but rejected because a signifi- 
cant amount of valuable data is stored in legacy (in-house) 
databases that are either custom -designee! witliin a company 
or are spread across many different vendors' tlat aliases, mid 
HI* would never have the resoirrces to tmild all the gateways 
needed to support commercial applications. Instead, we 
created an external fimction interface that acts like an exit 
subroutine in application code. Through this interface, data- 
base developers can access any code i>r data that resides 
within a conipany's netwfjrk. Oju^e external data is brought 
into the object manager, it can be integi-ated with data stored 
inside OpenODB mid put into a format that is a^jpropriate 
for the object-oriented application and the end iLsen 

System Environment 

The OpenODB server and all clients aie available on HP-UX* 
8.i) or later versions for the HP !K)00 Series 700/800 systems, 
and on MFE XL 4.0 or later %^ersions for the HP :300€ Series 
900 systems. 

OpenODB requires TCP/IP transpon mid ARPA Berkeley 
Services. The OpenODB graphical browser requires the X 
Window System. 
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Object Models 

There is no slaiKiard object model. The popular models in 
the programming Utnguage commuiiity are tlie C++ model ^ 
and the Smalltalk model.- These two models and others 
share many common features. 

The eommonly accepted definition of an object is something 
that contains data and code (called methodst) that operates 
on tlie data. This feattire L** kiK>wTi a*i5 encapstilation. External 
users retrieve or manipuJate the data sloretl in objects by 
sending messages to tiie object. Tliese messages are handled 
by the methods in the object. 

FYom a database standpoint , the data stored in an object is 
the object's attributes or its relationship to other objects. 
The relationsliip is topically represented as a pointer to an- 
other object. The methods are the possible operations on 
the object. 

For example, an employee object may have an employee 
identifier atid i>anie attributes (see Pig, 3). Tlie objed may 
also have information about the employee's health provider 
and who the emj)ioyee works For. Notice in Pig. 3 that the 
relationshii) infonnation is rcpresetited by pointers^ Opera- 
tions on data in an object may kiclude setting or retrieving 



data values in the object, or doing some computation on the 
dam. For ejianiple. in the employee object there is an opera- 
tion to add a provider to the data and another ojjeration for 
computing the total premiun^ for the employee. 

A data ai>siraction technique called classification abstrac- 
tion-* is commonly used in object models. In this technique 
objec^ts of similar characteristics dre mo<Jeleii usmg classes, 
A class is used to define tfie structure of the data pan of the 
object and the code that operates on the data structure. 
Each object that belongs to the class is called an instance of 
the class, and it has a copy of die data structme of the class 
and can be operated on by the methods specified for the 
class (see Fig. 4 j. For example, to define employee objects, 
we would define the class Employee. The class definition of 
Employee wotUd state the data structure and the niediods in 
some syntax. Once tlie class has been defined, any nmnber 
of instances (employee objects) can be created by sending 
an appropriate message to the class. 

Another abstraction technique called the generahzation/ 
specialization al>straction'* is also used for object models, hi 
this technir^ue, a superclass may be created to model the 
common chaiacteristics of two or more classes. Conversely, 
a classes characteristics may be refined by creatinj^ sub- 
classes. For example, we may define a class Manager as a 
subchiss of Employee. In this case every method and data 
strticture defitution applicable r{i the eju^jloyee object is also 
applicable to the majiager object. Fig. 5 shows that the 
classes Manager and Staff inlierit the metliods and data struc- 
tures from class Employee and also have their own methods 
and data structures. 

The OpenODB Model 

'llie OpenODB model is based upon three concepts: objeclST 
types, Jruid fimctions. OpenODB ol>jec:ts are still tnodeled as 
tlata and inethotls but data is nt) longer autoniatically private 
to the object. TVl^^s me used tti define functions^ iind fijnc- 
tions !:ue used to define the attributes, relat i<jnshipNj ami 
operations on objects. 
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abstraction tecliimjue called das- 
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lined for the cilass the instance 
belongs to. Nolo that the sajne 
nietlK^ds defined fcM" the claKW 
are used for all instance's of the 
I J articular class. 
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1 Data 
1 Struciuffi 


1 Morhoda 1 










Subcf asses to Employee Object 

Methods and Data 

Structuies Added to 

Those inherited 

frojn EmplDyeB 

Pig. 5. An illusiration of liie gpneralkatioit/spefiiaUisation data ab- 
stfaetioir technique. Here two objects Manager and Stalf iiifiprit f harar- 
teristics from tfie siiperckss Emptovee, Tiiey become subclasses when 
the niPthtxls and data stnitlure infierited front Employee is augmenied 
with tiew methodvS anfi data stnicttircs in oacti ol>jt^(:i. 



Object 

Ail objed Is a model (computer represenUition) of a thing or 
concept in tiie real world. Unlike data, wliieh ntadels the 
static aspects of the t.hitig such as it^s atthhiiles and relation- 
ships, an object also models tlie dynamic behavior in femis 
of tiie methods applical>le to the objec l. 

Conceptually, an OpenODB object is an encapsitlation of 
data and t>xJeraUons. However, there are two im[:foilanl dif- 
leiences between OpenODB objects ;tnti those defined for 
object-onented progianimiog languages (OOPL). Fln^i, ever>' 
data item in OpenODB is created as a 1 unction and is acces- 
sible and modifiable only through functions. Tins allows a 
uniform view of an object since there is no distinction be- 
tween accessing an object attribute and invoking a metliod 
that returns values. For example, supjaose the employee 
kientificalion number data item in the enifiloyee object is 
defmed as the function IDN with an integer retiini tyjje. To 
access the employee idcntilier, we w^ouid evaluate the func- 
tion lOMje). which is eqiuvaicnt to using a method in an OOPL 
model to access the employee's identification number in an 
empkiyee object e. The difference is that OpenODB does not 
suppoil slrictly local data items as does tlie OOPL model, in 
which local data items are <lirectly accessible only by the 
methods defmed for the object . With OpenODB, since every 
data item is a function, any usei' who has the proper access 
privilege can evaluate the function and modify the data 
associated with the object. 

It would seem that tliis model defeats the purpose of private 
data in the object-oriented methodology. However, OpenODB 
provides mechanisms for maintaining the concept of private 
data. Access control mech^inisms pio\ided ui tJpenODB me 
discussed later in this article. 



The second difference between an OpenOlXB objeri model 
and an OOPL object model is the way in which an object's 
data is organized. In OOPL, the object's data is st(jred in 
some (contiguous aiea of niiiin memory and the object's ref- 
erence is the address of tJie first b>te of this memory tuea. 
For example, a reference to an employee object is an ad- 
dress in memory in wiiich an instance of the employee data 
struct uri* is stored. In OpenODB. the object's data may be 
stored (either clustered or dispersed) anywhere in main 
memory or on disk. The reference to the object is indepen- 
dent of the data associated with tlie object. This allows 
OpenODB <.)bje(.t,s to evoh'e gracefully witliout reqitiring the 
schema to he recompiled every linie the object gains or 
loses data items. 

OpenODB supports three kinds of objects: surrogate, literal, 
and aggregate (see Fig. 6).t Surrogate objects represent 
tJiuTgs tir concepts in the application domain. Ttie cliaracter- 
istics of the thitig or concefsi that the surrogate represents 
aie obtained by applying relevant functions to iJie surrogate 
object. In OpenODB, a sutTogate object is identified by a 
unique object identifier (OID) that is totiiJly separate from 
any data lussoc iaied mih (lie object. F'xntnples of things that 
could h^ n I ode led sis surrogate objects iruliide per.s(>nSf em- 
ployees, parts, and manufarturing plants. SuiTogate objects 
may also represent entities used by the OfienODB system to 
manage Its own data such as the t.jpes and functions that 
keep track of OpenODIi objects. Surrogates niitst be explic- 
itly created and deleted either by the system (for systeni- 
defmed objects) or by the user (for user-defined objects). 

Literal objects are self-identifying in that they [vave exteinal 
(X>rintable) representations that correspond to welhknown 
concepts. For example the number 123 aiifl the string 'abc' 
are literal objects. 

An aggregate object is a set. hag, list, or tuple of other 
objects. Table I lists I he characteristics and some examples 
<jf aggregate objects. 

Tlie difference betw^een a list object and a tuple object is 
ttiat list objects and tuple objects liave different constraints 
on the object types that rtiake up their collections. Tliese 
differences are described in more detail later. Sets are 
subtypes cjf bags. 

In OOPL aggiegate objects are supported by built-in con- 
structs such ijs iirrays, stntctures, and a hbrary of predefined 
classes of aggiegate objects, 

T j^DLe ttrat liierai and surrogate ubjeeis arvd types afesomeiimes coflectiyeiy referred to as 
atomic Vms^ 

Object 



Alonifc 



Literal 
(e.g., 123, ahc } 



Surrogate 



System^Qefined 

i&.g., Functions that 

Manage OpenODB 

Objects} 

File, 6- The taxonomy of OpenODB objects. 



Aggregate 
I List, Bag. Set, Tuple) 



User- Defined 
(e.g., persons, pertsj 
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Table 1 
Aggregate Objects 




Jfpe 


Characteristtc 


ExanipJe 


Set 


ContaiJis nu duplicate 
elements 


Set(123/abc^j 


Bag 


May conuiiii dupUcare 
elenienis 


Bag(123423;ahc) 


list 


Ordered collectiDn of 
objects that may contain 
diiplirates 


lisi: r*ab " , *ba\ *ab' ) 


Tuple 


Ordered, fixed-sized 
collection of objects 


Tuplerlahr' 2i 



Type 

A type IS aji object that impienients the classification ab- 
straction technique described earlier. OpenODB types are 
similar to OOPL classes. However, there are two m^yor dif- 
ferences betw een an OpenODB type and an OOPL class. 

First, an OOPL class must have a declaration of the data 
structure for the data part of its object instance (if there is 
any data part for a particular object). Since an OpenODB 
object is independent ot its data part, OpenODB types do 
not have any data structure declaiation. The data for an 
OpenODB object is defined by means of functions on the 
type, and such functions may be defined at any time, not 
only when the t>pe is created. 11 lis dilTercncc can have a 
profound effect on the evolution of the application. Con- 
sider tiie following fragment of a data schema (written in 
hypolfietical syntax for OOPL) for an application. Assume 
that I he classes or types Company and Department have already 
been defined. 



OOPL Declaration 

Class Employee: 
Data 

IDN integer; 

Name ch3r(20|; 

Providers SeKCompany); 

Works In Department; 
Methods 



OpenODB Declarationt 

Create type Employee; 

Create function IDN(Einployee) 

-> integer unique as stored; 
Create function Name(EnnpJoyee) 

-> char{20) as stored; 
Create function ProvidersjEmployee} 

-> SetTypelCompany) as stored; 
Create Function Worksln(Employee) 

-> Department as stored; 



Tile OpenODB declaration could also be written as: 

Create Type Employee Functions ( 

!DN integer unique, 

Name char(20h 

providers SetTypelCompany), 

Worksin Department) 

as stored; 

Assume that sometime after the application has been in use, 
we decide to ijiciude date-of-hirlli information for employees. 
With OOPL, we would have to decliire the date-of-hirth tlekl 
in the data structure for the class Employee, define relevant 
methods for it, and then rficompile the entire applicatioru 

t The OpenODB program fjagrtFeftis used herB and irt the fes[ of the document BtB tjased on 
OSQL iobjBct-ofianred SQtJ, wh[^:h is OpenODB'ij database pragramrning lanfluaga 



With OpenODB we simply defme a new function DOB (date- 
of-birth) on object Employee to reium a date (which is a pre- 
defined t>pe). Funhemiore, the definition of a DOB function 
can happen even while tiie apphration is rimtung. 

The second diflerence between an OpenODB type and an 
OOPL class is that an OpenODB t>i>e has an extension, wliich 
is a set of instances of that type. This feature tacilitafeH 
queries over classes of tJbjecLs. For example, in OpenODB, if 
we want to obtain tlie name of an employee whose IDN is 
123456789, w^e simply pose a quer^^ as follows: 

Select name(e) for each Employee e where IDN(eJ = 12345678S; 

OpenODB is able to find the correct employee because for 
this example it keeps track of ail the objects of type Employee. 

Tlie taxonomy of tyi^es is topoio^caHy identical to ttie tax- 
onomy of objects because types are also di\1detl into three 
groups: hteral, surrogate, and aggregate. Literal types in- 
clude integers atid characters witli extensions that are pre- 
defined and infinite. An extension of a type is the set of 
instances that belong to the type. For example, 1, 2, 3... are 
predefined extensions of the literal type integer 

Sinrogate types include system and user-defined types* 
WTien a surrtJgale type is first create d^ the extension is 
empty. However^ the extension for a surrogate type expands 
or contractus as objects are explicitly added to or deleted 
from the type. For example, the fimction Create Person would 
create a Person object anti Store it in the extension of the 
type Person. 

The aggregate types supported are bag, set, tuple, and list 
types. They are referred to by type expressions c- on sis ting of 
constructors BagType, SetType, TupleType, mid Listlype respec- 
tively. Their extensions are automatically maintained and 
the user cannot explicitly insert objects or delete objects 
from extensions of aggregate tyiJes. For example, the tyt>e 
SeiType( Person ) refers to a t>pe whose instances aie sets of 
persons, if p is a person j then the object Set{p} is an instance 
of the type SetTypel Person). 

The difference between a list tyi^e and a tuple type is that a 
list lyi>e permits tlie specification of only orie tyjie for its 
members wliile the tuple type [leriuits the specincatiou of 
multiple types for its members. For example^ an instm\ce of 
the type LisiType|Person) is au ordered collection of any mmv 
ber of objects of type Person or its subtypes. On the other 
hand an instance of the type TupleType( Person, integer, char) is an 
ordered collection of three objects, the furst is of type Person, 
the second is of type integer, and the third is of type char. 

Open(JDB supports sub type/supertype relaliouships among 
types. The subtype/supertyiie relationship implements the 
specialisation and generalization abstractions described 
earlier. This relationship induces a directed acyclic graph on 
tire tytjes known as tiie OpenODB tyy^e liierarciiy (see Fig, 7j. 
The type hierarchy is rooted in the type Object. If an (jbject is 
an instance of a type, it is also an irLstaufe of ;dl the type's 
suiJerlypes. Thus the functions defined on the supcrlypes 
can be evaluated with instances of subtypes as atguments. 
Conceptually this is the same as subclass ir^heri lance in an 
OOPL For example, we can define the type Manager as a 
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subtype of the type Employee. Since by defmition members of 
subtypes are also members of supertypes, every manager is 
an employee. Hierefore, all the fiiiitmons defined on Employee 
call be appliefl t«) any manager oh j eel. We caji define addi- 
tional functions on Manager. PYir example, the function Super- 
vises(mj wiiicli takes a iniumger as aji aj"gumeni *uid returns 
tlie set of employees supervised by the manager, can be de- 
fined on type Manager, In general, tliis funcrion caimot be eviil- 
uat**d with an enu^loyee object as m\ argument because noi 
ail employees are mtuiagers and the function is not defined 
for limse who are not managei-s. l^^juiily. since OpenODB id- 
lows a given tyije to have midtiple superlypes, the inheritance 
IS actually mtdliple Lnlieritance (see TeachingAsstsiant in Fig. 7), 

Functions 

A function is aii object that represents an attribute, a rela* 
tionsltip, or im operatit^n on an object. A function maps t>l> 
jects from one ty^je to ot)j(?cts in another (not Jie<:essaiily 
distinct) type. A function has one aigument type, one result 
type, a result constraint, anti an extension consisting of a set 
of tuples. 

The result constmint can be specified for functions stored in 
the database (stored fimctions) only. If the stored functions 
result type is mi atomic t>pe or a tuple type of atomic types, 
the result constraint can be specified as unique or nonmuqiie 
(default). A unique constraint states that the function will 
never produce the same results for two differcjit argimients. 
For example, the funcMiun IDN will never retuni the same 
integer for two cUfTerent em])l(>yees. More iniportiuU, a unique 
coastraint will not penuH setting lJ)e sanie number as the 
result of two different iirguments. For ex^unple, two em- 
ployees cannot be updatetl with the same IDN, ollierwise an 
eiTor will occur. For a fuiu:tion whose result lyi>e is SetType, 
the result constraint can he speciHed as disjoint or nonclis- 
joint (default). The disjoint constraint states that the results 
of two different arguments will never overlap. For exaniiile, 
the function WorksforjmanaQer} -> SetTypeiEmployee} returns a set 
of employees I hat work \'or a paiticulai' majiagei'. Thus, 
Worksfor^john) returns {mary, jack, jill}, mid Worksfor(henry) retimis 
(Gatliy, a be, torn}. Each call results in a distinct set of names 
being returned. If the residt cortstraint is nondisjoint and jack 
works for John and henry, then jack would appem' hi both .sets. 

Table U smiuriarizes the types allowed to be assigned to func- 
tion parameters and the relationships between the instances 

Obj&ci 



Table tl 
Function Parameters and Their Relatmnships 



Userrype 



Person • • 



Student 




Teach ei Manager Besearchei 



Argument 


Result Type 


Result 


Retettonship 


Type 




Constraint 


Modeled 


A 


R 


Ifnique 


One-to-one 
(e.j,^. IDN to 
emi>loyee} 


A 


R 


Nonunique 


Nf any-to-one 
(e.g., em- 
ployee to 
tuanagerj 


A 


Set of R 


Disjoint 


One-to-many 






- 


{e.g., manager 
to employees) 


A 


Set, Bag, or 


Nondisjoint 


Maity-to-many 




[Jst of R 




(e.g., skills to 
employees) 



Teacliing 
Fig. 7. Ai\ example of OpendfJB subtype and supertyiw rnlationslTips. 



A = R = atDfnic types or tuple of atomic types 
AtDmic = literal ar sejcrngate type 

of atoniir t>^7es and a tuple of atomic types that are morfeled 
by the different pat an^eter settings. 

The speeiQcaiion of the function name, its argument and 
result types, and tlie result constraint constitutes the decla- 
ration of a function. t Like types, functions also have exten- 
sions that represent tlie attributes of and relationships be- 
tween objects. Fcjf example, consider the ftmciitm Name 
which is defined on tyi)e Person, This fuuclitjn lelunis a 
stilng of characters whenever It is called with the appropri- 
ate paj'anieter A set of t)bject iilentifier and string i)iiirs 
makes up tl^e extension uf tlie Mame function. For' exanipie; 

{<DIDh John><OI02, Harry><0ID3, Helen> ..} 

where OlDn represents the miique object identifiers and the 
nmiies represent the strings of type Person. TJie declaration 
and implementation of a function ntay lake place at difl'urent 
limes in the tlalab^ise sclu^ma creation. The implementation 
of the function can be ci^anged wiiliout recompiling the ap- 
plications (altliough lire ilatabiise functions may have lo be 
recompiled). 

A function can be implemented as a scored function, a 
derivetl fimctioji, a computed fimction, or an exlenuil func- 
tion. Derived mid computed functions are collectively knowTi 
as (.)SQLr based limctions. 

Store li Fimction. hi this case the extetision of a function is 
stored m an SQL table. For example, tlie functions IDN. Mame, 
Provfders, and Worksin are stored functions. Their result values 
can be assigned iuid modified by the user. The following 
script creates an employee and assigns an employee identifier 
mid a name. 

Create Employee e: 
IDNIel:- 123456739: 
Name(e):= Smith'; 

t Ihe argument type or the result V0B could (re VOID, in which case the lunctjoit has m argih 
ment or rrn result re^pectivel'j' Functions v^ilti no leault? are typicaUv lised to model database 
update Dperatitin^ 
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Derived Functiofi. In this case the extension is describecJ by a 

quorv using other ftinctions. This is analogous to \1ews In 
the relational data model. For example, assume we have an 
overloaded function caUed Name and we want to create a 
function Employeeinfo that returns the identifier, employee 
name, and department name for a given employee. We could 
use Lhe following script: 

Create functiofi Empfoveelnfo^Emplovse e) 
-> Tuple^pedntegerCharXhar) as osql 

select single IDN(etNameie),l\[amefWorkstnle}|; 

In this example. Employee fnfo is not stored, but derived from 
the functions \W, Ma me on Employee, and Name on Departmert 
and Worlds In. L-nhke stored ftmctions, not ail derived hmctions 
are updatable. 

Comptited Function. In this case the extension is described by 
a progiam wiitten in OpenODBs datatiase progimnming Ian- 
^lage OSQL. For examjile, Lf we w^ant to e^^rnerl all m^magers 
who have less than a specified number of employees to pro- 
grammers (assume that Programmer is a subtype of Employee), 
we w^Duld wTiter 

Create function MgrToEng {Integer minemps) -> Boolean 

as Qs^\ 
beg in 
declare SetTypet Manager} mgrset 
declare Manager m; 
r get ail the managers in mgrset 7 
mgrset := select distinct atomic m for each Manager m; 
for m in mgrset do 
if (count(Supervises{m)) < minemps} 
then 
/* convert a manager to a programmer*/ 
begin 
add type Prggrammerio m, 
remove lype Manager from m; 
end 
endif; 
end; 

External Function. For an external fimction OpenODB uses 
co<le outside of itself to ohtain the extension of the function. 
The user specifies how- to invoke t!iis code. External code 
can be specified to be invoked in the following tliree ways: 
* Speedy lhe implemenlalirm lo be SQL and provide an SQL 
statement to be executed to obtain the extension. This is 
used 10 access SQL databases. For example, assume that 
there is a table EMPHiSTQRYflDW. DEPT, JOBDESC) in an Admin 
database that describes the employment history of em- 
ployees. We could create a function in OpenODB lo access 
this infonnation as follows: 

Create function EmpHrstory( Employee e) 
-> b a g ty pe { tu p f Btvpe{ C h a r, Ch a r) | a s externa I 
SQM'AdminVJSmith'/tinmSJ', 

'Select DEPT.JOSDESC 

from EM PHI STORY 

where iDN-:xUist(SSN{e})}; 

Here tlie fu*st argument to SQL is the dauibast^ name. It could 
be spe(*iried as NITLL in which case the currenl: database 
would be used. To access remote SQL dalatnises, ALLBASE/ 
Net must Im^ installed, and the database nujst b<^ registered 
In AliasDB/^ Tl\e second jmd third aigunipnts are the user 
name and the user passw onl respectively. If the second 
argument Ls specified as NULL, the ihird nmst tdso l>e NULL, 
and in this case the default user is used to access the SQI^ 



table. The fourth argument is the SQL statenieni to be 
executed. It may contain references to host variables such 
as :x. The fifth parameter is a list of values to be substituted 
for the host variables. In this example, IQN(el will be e%*alu- 
ated and the resuJdng string will he substituted for :x. A con- 
nection will be made to the current database (if one does 
not exist ) using the user name and the password. Then the 
quer\^ will be executed. The result will be converted to 
OpenODB format and returned to the caller 

• Specify the inxplementation to be OsCommsnd (an OSQL ftinc- 
lion tied to operating system commands) and pro\1de the 
operating system with the command to be executed to obtain 
the extension of the function. For example, we could define 
a function Dir to look at a listing of the current directory in 
HF-IX with the following OpenODB function. 

Create function Dir(Chard) -> bagtype(char| as 
external OsCommand (1s$d1; 

• Specify the implementation to be GeneralExtFun or SimpfeExtfun 
and provide the names of three routines (for GeneraJExtFun) 
or one routine (for Simple ExtFun) that are Imked with the user 
appUcation. For GeneraJEjctFun the first routnie Ls used to open 
a scan on the result of the fimction for a given argun^ent. 
The second routine is used to read the result objects. The 
thu-d routine is used to close the scan. SimpieExtFun can only 
be used for functiotis whose result tyj:»e is atomic (literal or 
siuTogate) or tuple type of atomic. Wlien called, (he specified 
routine must retuni the result for a given argument. 

To show how SimpfeExtFun is used to implement an external 
function suppose we have a C program chilled CreditRating that 
computes the credit rating (an integer ruimber) of the per- 
son with the given identifier (assume a 9-character string). 
We could make tlie C program the body of an OpenODB 
fimction called CrRating as follows: 

Create function CrRating^char p)-> char as external 
SimpleExtFLnrCredJtRatingM; 

SimpieExtFun is appropriate here since the C program will 
return a single integer number for each argument. 

Let us now consider an example that itses the general exter- 
nal functiori to implement an external function. Suppose w^e 
have an 0|kmiOIJB funcrion called JobHist that returns the job 
history of a person as a array of charatler strings. We coidd 
define an OpenODB function that uses the following C code: 

Create function JohHist(cfiar p| -> BagType(char} as external 
Genera!ExtFun('JobHistOpen';jobHistNeKt';JobHistClDse'l; 

Here, JohHistOpen. JobHistNext, antlJobHistClose are t hree r ou- 
tines written in i\ WTien JobHistOpen is trailed with a person's 
identifier, it should create a scan data structure and return a 
pointer to the data stnicture m an integer number Otie pos- 
sible way to unplcment JnbHistOpen is to have the routine 
allocate storage for the relumed array. JobHistOpen can then 
return a pointer to a struct u re that contains an integer num- 
ber atid a pointer to the array The integer numljer (tniti^d- 
ized to -1 ) keeps track of the the next element of lhe array 
to be retunied by JobHistNext. Each time JobHistNext In calknl k 
is given the pointer obtained from JobHistOpen. JobHistNext 
increases the integer number of the st ructure, accesses the 
array element at that location and retiims the string, \\lien 
JohHistClose is called, it is given lh<' pointer obtained from 
JobHistOpen, JobHisiClose frees the slonige I hat w^as allocated 
by JobHistOpen. 
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The extensions of ail storetJ runctions and sonie derived 
functions can be t^hangeri by aiilliorized users. Sijrh a 
chiuij^e iH iux'ontplisiieci by update riuicUoiis associateri wjih 
the original function. These update functions lire automati- 
cally generated by the system for updatable functions. For 
example, for the stored fmntion Name on Employee, the sys- 
tem might create an updale funclion railed Updnanrie. whic h 
takes die OID for an employee ol>JecT ;nif1 a string olijeet iuul 
creates ;ni association between the two, Tiius, after using 
the Updname function with an Employee olijject that has the 
identifier OID 123 and a string labeled 'Smith* as pai^neters, 
refert^nces lo OID 123 will be associateti witli 'Smith' and vice 
versa. 

Function Name Overloading 

OpcnC >rJH supporl.s huictitin name nverloadiug. Many func- 
tions can liave Uie same name t^ut different argument types. 
For example, in the functions Weighif Parti and Weight! UnitI, the 
fuiiction Wejght( Parts retiuTis the weight of ^ui individual part 
iuid the funclion Weight! Unit! returns the weight of all the 
parts on a particular unit. 

The functions iJiat are explicitly created by the user are 
known as specific functions. For a set of specific functions 
with the sanie name, OpenODB creates a function called the 
generk' func*tioni whose name is f he same as those in the set. 
However, the gerteric function has no implementation. The 
name of a function by itself refers to the generic funcrion 
and is called a generic huuijon reference. Howeverj if the 
name is followed l>y a ty]>e reference sepai^ated by a period, 
t hen it refers to a specific funcfion, ajid such a reference is 
callerl a specific function reference. For exjunple, if function 
Weight is defined on type Part, the generic function reference 
is Weight and the specific function reference is Weight Part. 

Since the generic function has no implementation, it cajuiot 
be directly evaluated- It must first be bound to a specific 
function. OpenODB supports late binding of a generic func- 
tion to a specific function. If a generic funclion is used in M\ 
evaluation, tlien the specific function to be used is deter- 
mined bsLsed on the actual argimient at nm time. However, if 
a specific fimction is used in an evaluation, then that spe- 
cific fimction is used reg^urdiess of the argument (thc^ argu- 
ment nmst be an instance of the argument lYV^y Thus spe- 
cific function reference supports early binding. 

For example, assume that we have the generic function 
Salary on Employee that returns the salary of a given employee. 
Suppose we want a manager's salaiy to inchide the bonus. 
We could overload Saiary on Manager to return the sum of 
the manager's salaiy and bonus as tlie following example 
illusti^ates. 

Create function Salaryf Employee e) -> Ffoat as stored; 
Create function Salaryf Manager m) -> Float as osq! 
saEary.employeeiml + iionustm); 

If e is an employee but not a maj^ager, then Saiaryie) wiU retuni 
the salar\' of employee e. Howe\ er, if e is dso a manager, 
Salary! ej wiO return the sum of the salary of e as an employee 
plus the bonus of e as a manager 

hi some cases, mapping from a generic fimction to a specific 
function is aiiibiguous. This happens because objects may 
belong to multiple types and there may be more than one 



specific function defmed on those t>pes, OpenODB does not 
prescribe defauU seruautics for choosing a speeifK- function 
in case of ambiguities. Instead it reports an error. 

Aeeess^ Control in HP OpenODB 

One of tiie functions of a database management system 
(DBMS) is access control. A DBMS must t)revent unautlio- 
riz€*d access to data stored in the database. Although com- 
mercially available DBMSs do have security subsystems thai 
support access contiol, support for authorization in object- 
oriented and functional database systems has not yet been 
fully addressed. In such systems, authorization features 
must interact with advanced model and language features 
sucii as user-detlned operations, encapsulation, nmltiple 
inheritance, generic operations, and late b hiding. 

Object-oriented laJiguages inherently provide some form of 
access control in the way abstract data types encapsulate 
private stale information.^' Although abstract data types 
pro\if.le supi^ori for access control at the inmlementation 
level, there si ill remains the need to protect data ai the 
organizational level. 

The authorization model in OpenODB is based on the notion 
of controlling function evaluation. Only a single pri\4lege, that 
is, the privilege to call fuuctiims, is necessar>' lo support an 
authorization nujdel that is uuire powerful and has finer 
levels of access granuiarity than the traditional authorization 
model of relational databiises.^ 

The Authorization Model of Relational Systems 

The basic authorization model of standard SQL can be char- 
acterized by a matrix captured by a relation schema 
(S,0,M). S Ls the dcjmain (jf all subjects that access the data- 
base system (users, processes J^ O is the domain of objects 
(base relations and \1ew^s ), and M is the domain of access 
operations (SELECT, lf\fSERT, DELETE, UPDATE, and ALTER).** 

Most RDBMS miplementations suj)port the notion of owner- 
ship. Each databast^ schema has a designated system admin- 
istrator, datal:)ase administrator, or database creator who is 
the (jwner of all objects created in that schema. Further- 
more, the creator of m\ object becomes tiie owner of the 
object and typically holds aU privileges on that object. 

An object owner can grant access to the object to o!her us- 
ers. Commercial systems implement mechanisms t hat allow 
the owner to gi^it SEtECT. INSERT DELETE, UPDATE, ajid ALTER 
pri\i leges on objects to other us en? selectively. Fiirtlieimore^ 
an object o\^iier can pennit a GRANT pri\ilege on the object^ 
thereby enabling other users to finiiier grant pri\aleges on 
the object. 

Authorization in OpenODB 

Many of tlie concepts developed for relational database au- 
thorizarion are fundamental and are applicable to other 
technologies such as object-oriented database management 
systems. These fimdamental concepts include ttte notion of 
oiATiership, users and groups, pri\i leges, and granting ai^d 
revoking pri\ileges. The authorization model of t^>enODB 
uses many of these fmitkunental concepts. 
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Users, Groups, and Owners. Users are modeled by the (^n- 
(JlJB type User, ^vhich Ls <'haracterize<t by a sei of functions 
that create and destroy user objects, return valid user 
names, and match passwords- For example the strii^: 

Create User 'Smrtii" Password 'jc012' m tester. 
Create User 'Janes' Password yZ m engineer, 

create the users Smith and Jofies vviih their respective pa^ 
words and assign Smto lo the group tester and Jones to the 
group engineer. 

Users can be classified by groups, Pri\41eges granted to a 
group apply to each user in Uie group. TVpifaliy, users are 
classified based on their roles;^' ^^'^^ ^ ^^^ A user can belong to 
mulriple groups thereby accunuilating tj^e privileges from 
each individual groujj- Furthennore, groups may be nested. 
A nested group inherits the privileges of the nesting groups 
similar to tlie way functions are inherited by a subtype from 
a supertype. 

A grou[> is an object in OpenODB that is modeled by the 
type Group, A group has attributes such as nanie and mem- 
bers ant J is made up of either individual users or other 
grou|>s. lypit^"^! fimctioixs defined on the tyi>e Group include 
functions for creating and deleting grouf^s. for adding and 
removing subjects, for returning group meuibers, and for 
granting anrl rev^oking call i>rivileges. The Ibllowing state- 
ments create the groups speririec! for the users Smith and 
Jones in tlie exaiupie above. 

Create group developer; 

Create group engineer subgroup of devefoper; 

Create group tester subgroup of developer; 

The access-control hierarchy created for these functions is 
shown in Fig. 8. 

The user who creates a given function is said to he the owner 
of the fmictiun. Tlic owner of a function automatically has a 
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Fig* 8, An example of an gccess-fontml hk^rarchy in DpenODB. 



call privilege on the function. Furthennore. the owTier can 
grant call privileges to other users using tiie Grant function 
which is described in the next section. 

The group hierarchy is rooted in the group PubJic which has 
call authority on common system functions such as Connect 
and SelecL Every* authenticated user by default belongs in 
Public. 

Database administrators (IJBAs) are siJef^ial users with more 
privileges than ordinary users. For example, DBAs have all 
tJie privileges implied by function ownership. 

Granting and Revoking Privileges. Call privileges can be 
gnmied aini revoked on a per-group liasis, Prrvileges can be 
granted unconditionally using the Grant statement or condi- 
tionally using the Grant statement with an IF option. Wiih un- 
conditional privilege granting, ai^ authorized grout^ member 
can call a fimclion for all possible argument values. For ex- 
ample, if the user Jones from the exiunple above wants to 
graiu a t^iill t>rivilege on the salary of employees to the group 
tester, the OSQL statement woidd be: 

Grant call on salary to tester. 

For granting a conditional privilege, a predicate (Boolean- 
valued function ) is associated with the group and the func- 
tion. Tlie piedicate lias the same atgumcnt type as the fimc- 
tjon. When the function is called, the iirgument is used to 
evaltiate the predicate. If the predicate returns true, the user 
can call the function with that argument. For example, sup- 
pose user Jones wants la grant the privilege to tester to be 
able to inotlify the salar>' for part-time employees. First the 
function lo filter part-tin\e employees Ls created; 

Create function SaiaryGuardiempJoyee e, fbat saJ) -> 

Boolean as OSQL 
begm 

if (statuslej = 'pan-time') return TRUE; 

return FALSE; 
end; 

To grant the privilege to tester; 

:f ;= funassigntfunction saJary.emplDyeel; 
Grant cbII on :f to tester if SalaryGuard; 

The OpenODB ac^cess control model is based on the single 
concept of controlling function invocation by allowing only 
authorized grou]:)s access to a function. The OpenODB ac- 
cess control mechanism does not impact the performance of 
the owmer of the function, the database administrator, or 
other conunon OpenODB services. 
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The HP Ultra VGA Graphics Board 

By increasing the display memory to 1 M byte and providing some local 
graphics processing, the HP Ultra VGA board is able to Increase VGA 
resolution to 1024 by 768 pixels with 256 colors at all resolutions, 

by Myron R. I^ittle, Kenneth M. Wilson, Sajtiuel H. Chau, and Yong Deng 



Tlie HP r)23'25A ntra VGA board, whirh represents the latest 
m the evolution of HP penjonal computer ^adeo systems, is a 
video accessory card for tlie HP Vectra line of personal com- 
pulers. Thb board offers exceptional video performance foi^ 
graphics-intensive applications such as Microsoft - Windows 
and AutoCAIF^V It enJiaiK-es overall system performance by 
using hardware accelerators to relieve the CVV of common 
\ideo processing fmicrions. For liigh-i-esoliition mid nicker- 
free operation, the Ultra VGA board offers display resolu- 
tions up to 1024 by 768 noninterlaced and refresh rates up to 
72 Hz. Finally, the board is upgradable to IM bytes of video 
memory to give 256 colom in 81)0 by GOO and 1024 by 768 
resolutions. 

In tJiis article we present a brief history of the evolution of 
PC video systems. We will then discuss The benefits of a(id- 
ing acceleration to video hiudwai'e and tlie hardw^are and 
software partitioning trade-offs that must be made. Fii^ly, 
the implementation of the HP Ultra VGA board is ciescribed, 
both as a plu|{4n accessory and ;is ai^ embedded featiue as il 
is in the HP Vectra 486/U family of personal computers. 

Evolution of PC Video 

1981 marked a dram a Uf change in die world of computuig 
because that was the yem- the^ IBM persoiud computer was 
iiilroduced. The First IBM Ft' came etiuipiied with 64K bytes 
of RAM and au alplumumeric Mont>chrome Disfilay Adapter 
(MDA). Tlie Mt>A containcxl 4K li>1es ofmemoi^^, enough to 
store one screen (25 lines of 80 cliaracters each ) of altjfmnu- 
meric infonnatioir The PC with one of these adapters func- 
tioned like most terminals available at the time. It had veiy 
clean alphamimerics but lacked any graphical capabilities. 
Until the introduction of the MDA, virtually iill PCs or "home 
comijuters" such as the Apjjle 11, Conunodore PET, and the 
Ttuidy Radio Stiack TRS-80 used a television mcjnitor or a 
modified television monitor as a display, grossly limiting the 
resolution. 

Also avaiJabie from IBM in 1981 was tlie Color Graphics 
Adapter (CGA). Tliis adapter contiuned 16K b>tes of niemoiy, 
enougli to liokl torn- aJtJhjuuimenc pages and provide hniited- 
resolution graphics. The graj^hics capabilities of tlie CGA 
allowed It to display 320 l)y 200 pixels in four colors, or (>40 
by 200 pixels in two colors. The price of niemoiy was still a 
limiting tactor in display resolution. Tiie 2()04ine vertical 
resolution severely impacted the CGAs aiijiiammicric capa- 
bihties because all charactei^s were displayed in an eight'l>y- 
eight ceil and were ditficull to read. Several comptudes^ in- 
cluding Hewlett-Packard, introduced their own extensions 



to the CGA. allowing greater resolution. The HP 45981 A 
midtimode adapter increased the resolution to 400 lines but 
kept tlie same horizontal and color resoluUons and increased 
the memor>' to 32K b\tes. The CGA became the lowest com- 
mon denoniinator for graphics-based programs and, ui fact, 
is still supported today by many apph cations— especially 
games. 

In 1982 the HercuJes Company introduced the Hercules 
Grapliics Caid (HGC). This adajjter fully supported the alpha- 
numeric capabihties of the Monochrome Display Adapter as 
weO as provithng 720-by-:^48'pi3{el monochrome grapliics. 
Because of its modest cost and industry support, the HGC 
became very popular. 

The next big breakthr{>ugh in PC video came in 1985 when 
IBM introduced die Enhiinced Grapliics Adapter (EGA). 
Tliis was the first affordable PC video adapter to enter the 
'liigh-resohition" arena It sutjported a resolution of 1540 by 
350 pixels with up to 16 colors simullaneousiy disj>layed 
from a palette of 64 coloi-s. Tlie nicmoiy required was 128K 
bytes. The EGA w^as fully backward compatible with the 
CtiA (and witii the monochrome monitor, the MDA). In H187 
the IBM PS/2 line of PCs was introduced ^uid with it the 
Video Graphics Array (VGA) video adapter The VGA has 
become the de fac to standard of tlie PC industry^ today. The 
original VGA ctjniainerl 256K b.yles of vitleo menioiy aiid 
supported resolutions up to 640 l>y 4H0 pixels with up to 16 
colors simultaneously displayed frtjiu a palette of 262,144 
colors. As memory prices have cont imied to decrease, the 
VGA has been enhanced. The first enhancement w^as the 
Super VGA (SVGA) which increased the resolution to 800 by 
600 (or 1024 by 768) pixels. The color depth mcreast?d to 
allow up to 256 colors to be simultaneously displayed. Dis- 
play memory was increased to 5I2K bytes. The VGA is fully 
backw;vf:i compatible with the CGA, EGA, and HGC video 
adapters. 

The video adapters mentioned above map Uie display iiieni- 
ory into the system processors memory space. All video and 
graphics operations are handled directly by the system pro- 
cessor. Newer display adaptei-s, sufii as the flP Ultra VGA 
board, have taken the next step by increasing the VtiA reso- 
lution to 1024 by 768 pixels with 256 colors available at all 
resolutions (increasing the display niemoiy to IM bytes) and 
jjrovithng some local graphics processing in the vide^) dis- 
play system. This frees tlie system processor from much of 
the work of updating t he display and accelerates display 
operations. 
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HP Ultra VGA Board Implementation 

In aiiy design there are aJways trade-offs to improve perfor- 
mance, save board .spajc;"e, add more features, and so on. The 
l.lti'a VGA board ijiiplemeritalion was confronted wi\h some 
of these same IxadcMjffs as well as the need to adoi>t Home 
new technologic?^ to provide a higlvresolution, Oirker-tVee 
graphics system. 

Software versus Acceleration TVade-offs 

In ainiosi all nt)nscientil1r (irognirns, vitleo ]jroressing is the 
perfonnanre l>otUeneek. By taking some of tlie graphics 
burden off the applications, a good video solution is able to 
improve overall system performance dramatically. This is 
especially tme as grapliics-oriented user interfaces become 
more pop ulai". 

Performing fiie liigh-tevel graphics functions like area fill 
and line drawing inside the hurdwaie has only become poiJ- 
ular bi the last few years. The MDA and CGA video solutions 
used video routines located in the* main system BIOS (bEisii^ 
inpiiL/oiitput system) of the eomiJiiter and offen^ti a few kjw- 
resolution modes. The EGA and V(tA were logical exten- 
sions to MDA ajiti CGA. They offered more modes, higher 
resolutions, more colors, and had their o\%ti \ide(j BIOS* 
Tliere was no sujipoil for any high-level graphics functions, 
though a few sin^plc graphical mixing fimctions like XDR 
were available. It wasn't until the IBM 8514 that iiigh-level 
graphic runctioiis were perfonned in (he Iiardware, The 8514 
is an aeeelerat.ed display adaiiter tliat ronlains a graphics 
engine implenienled in hardware. The [irtibleni with ihe 
8514 is that it is not l>ackward C(jrupa1ii)le with VGA. 

Since the advent of the 8514, other video manufacturers have 
started to put high4evt4 graphics fimctitjns and suj)port for 
VGA on the same card. Some mamd^acturers add tlie capa- 
bilities or high level graptiics fiuu lions directly t.«> the VGA 
modes w bile olliers acJd special \idet> modes and VGA modes 
that have the extra capabilities the 8514 made popular 

Trade-offs must be made to detemiine where the high4evel 
gmpliics fimctions like line thawing are implemented. In the 
p^ist, an application would use tlie GPU to calculate all the 
points in a line ;ind then write each sep*irat€* dot in the line 
to vkh^t) memory'. This works veiy well if the ('PI ' has l^and- 
width to spare and ail video solutions liehave the same. 
Smce all video solutions do not work the same, each appb- 
cation has to eitlier pander to the lowest common denomi- 
nator or not w^ork on all machines. T^vo main solutions to 
this prolilem have been implemented: video BIOS interrupt 
calls and application diivers. 

The HP Ultra VGA video BIOS contains an industry-slandard 
set of interrupt calls Uiat chajtge the configuration of the 
\ideo adapter, get info miat ion aliout the \ideo solution, iirid 
access all of the timctions needed to work with text. All ai>' 
pUcations thai know about the VGA standard can use these 
mtemipt cabs to perform the \ideo BIOS functions. This is 
great for text, but there is almost notiung in the VGA BIOS 
that helps with drawing objects in graphics modes. Since 
graphical user mterfaces aie now^ beconiing vei^' populai'. 
graphics support is very importajit. 



Display Driven The display driver fills the graphics support 
gap. A display driver is responsible for providing the means 
to tnmslate application grapliics conmiands to hardware 
commands and simulating capabilities not directly jirovided 
in the haidwaie. Each dist>lay tiriver is tmlored to ti st>ecific 
application. Every ai)plicati(a\ designer decides on the 
giapiiics commands needed and how^ they will be imple- 
ment e<l. In the same way^ each video chip maker clu>oses 
tlie graphics commands to implement in haidware. The ap- 
plication must supply a driver for eveiy diiTerent \ideo 
adapter it must nm on (or the hardwaie manufactmcr nujst 
supply a diiver for every application it wants to support). 
This allows vkieo mmmfaeturf^rs to produce soft wiu-e that 
allows spec! lie api>ii cations to run at peak peri'cuTuance oi\ 
their hardware. 

The combii^at ion of display drivers, BIOS, aitd hardwaie 
provides the excellent video perfonnance seen with the HP 
Ultra VGA video solution. The HP Ultra V(;a Ijoard not only 
suptjorts all of live modes that VGA contains, but tiJso has a 
set of enhanced Ivigb-resohition modes that use a graphics 
engine to accelerate the most commonly used graphics func- 
tions. The enh^mced modes are not standtud VGA modes, but 
applications can gel a<'cess to them via the display drivers. 
Tiie drivers iricrease a[)i)hcation j'^'riormance Ijy taking a 
high-level graphics operation like rectangle till and perform- 
ing itie operation a^^ fast as the video iiardware can do it. 

Applications send the display driver all graphics-related 
operations and the thiver decides the best way to |.KMlonn 
those operations. For example, to swittii fnjnt nu>de three 
(text) to mode 201 (enhanced graphiis) km ai>];)hcation will 
senfl the driver the conunand to make the mode change. The 
tiriver then has to decide wbetiter to make the mode change 
itself or send the command to the \ideo BIOS. T^'pically. the 
driver will call the \ ide<j BIOS for commimds like motie 
chmiges. However, for commands like line drawing, the 
driver will usually connnunicate directly with the hardw^are 
to draw the line. 

The implementation of display drivers is described later in 
tliis article. 

Graphics Engine. The graphics engine is a state machine in- 
sick^ the video ASIC on tlie IIP Ultra VGA board (see Fig. I). 
Its tiurpose is to perfoiin the high-level graphics fttnetions in 
hartlware so that the CPU is free to do other t^sks. An eight- 
word FlFt) buffer is provided so that the CPU can send all of 
the commands needed fot* at least one operation (the num- 
ber of cotnmands varies lietween operations). The FIFO 
reduces ttie artiount of time the CPU has to wait when the 
graphics engine is still perfojinuig its last command. 

The high-level graphics functions supported by the graphics 
engine m elude rectangle fills, line drawing, short stroke vec- 
tors, hardw^iye cim?in\ bit-block transfers (Bit Bit), anil unage 
transfers, Reetatigh^ liil is the ability to fill a rectanguhu area 
of videt:! ItAM with some si>eciric color cUid at the same time 
ciiange what is already at thai sped tied kjcation in \ideo 
RAM. For example. Oiling an ai'ea wkh all ones and the XOR 
operation will invert all colors Q>Lxels) within the rectangle 
speciiied. 
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Line cirawin^ is the ability to tiraw a liiie between any two 
points, Stiort stroke vectors are a special case of line draw- 
ing in which short Imes of sixteen dofs or less are drawn at 
any foriy-nve dt^grce angle (see Pig, 2}, Each short stroke 
vector takes only one byte in specify, and the graphics en- 
gine can accept two bytes at a lime- TliLs is veiy haiidy for 
shapes that use many short lines» like characters, and since 
only one byte is sent per Une, this operation is very fast- 
Bit block and image transfers are for moving rectangular 
htiagcs aniund in video memory-. A BitBll is (tie fast trmisfer 
of a rectangular image from r>ne lot^atifHi in video memory to 
another. Since the CPl' tinly lias to spt^ify the stjurce and 
destination coordinates atid rectangle size» it <^ari do otlier 
operations wink* the gmphics engine does all of the work. 
The BitBll operatii>n is t>erformed hy the VVV llrsl writing 
the sonree, destiiuition, and rectangle size to the MF(> buffer 
if the FIFO luis enough emjity entries (tlie Cf*l^ requires fi>ur 
empty entries for iJiis ojx^rationj. Tlien tlic CPU writes a com- 
niatid word tf> Ilie FIFO that tells the graphics engine what 
operation to perform. As soon as the connnand word propa- 
gates through the FfP'O and tJie graphics engine receives lu 
the operation begins imtneclialely. The graphics engine will 
read pixels h'oni Ihe rt^emor>^ within the source rectiingle ymd 
the (xjrn^sponding pixels from the destination n^ctimgle. The 
grapfdcs engine mixes the two sets of data \n any of 256 dif- 
ferent conibinaiions and then writes the resulting pixels lo 
the destination rectangle's video memor>; Tins will continue 
innil iill (he tjixels in tlie destination reiiangle are ^^ritten. As 
soon as the graphics engine has completed this command, it 
will go back to ihe FIFO for the next command. 

Image transfer performs the same function ;as a BitBll ex- 
cept that it transfers iiit image from the CPII memoiy to 
video memory and vice versa. For this operatior)^ (he CPU 
only has to compute the mimher of bytes to be transfeiretl 



Fig. i. A simpimod block dia- 
gnuti of tUi^ lilSra WA Ixmrrl 

and then write (or read) that nunrber of h>tes to or from a 
dedicated I/O register 

Since the graphic fimctions named aI>ove are constantly 
used with any gra|>hical user interface, a large perfom^ance 
gahi will fie seer\ on any bencfunark that tests viticfj using 
these graphic operations. Since \ideo is oil en tlie j perfor- 
mance bottleneck, af >p I i cat ion-level bent^hmarks tend to 
improve as we If 

After the CT'tT offloads operations to the graphics engine, it 
checks the UFO to make sure that there is enough room 
before sending the next command, rhis melius that the CFV 
might still have to wtiit (when the FIFO if full) if all it is do- 
ing is sentling high-level \ideo convmajids, For benchmarks 
that do a large nund>er of one tyjje of operation, the results 
may not indicate rt^al perfonnance. Because fjf this fact, 
i^enchtnarks today are nn>\ing towards using reiU at>j)Iica- 
tions perfonning nomial operations tiiat can be completely 
automatetf 

Today the mosi useful henchjnarks are applications that use 
a graphical user interface, liecause of t his, mimy Pi ' bench- 
marks measure the performance of grai)hically ijUeiisive 
ai)pIicaiions surli as CAD tirograms. 'IVtJ industry l)ench- 
marks, one naming on Microsoft Windows and the other on 
AutoCAD, showed that HP Vectra 48(t/l " tnachines using the 
HP Ultra V(iA card significajitiy outperformed oiher PCs 
nmning tlte same benchmarks. 

Host Bus versiiiS the ISA Bus 

Peripheral adajjtej cards are generally connected to a PC 
via the ISA (Indusliy St;mdajd Architecture) bus, which 
nnis at approximately 8 Mlfy, (aCLK). 8CLK Ls the IhjA chxk, 
which is olJtained by dividing tiie VIV clock liy either three 
or four depeiuiiiig i>n wlietlier the processor <"lock is 25 MHa 
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Fig* 2* Ca) Short stroke veator directions, Cb) Byte encoding af a 
short stroke vector, (c) Exarnple of a cJiaracter cliaTMi using i^hort 
stroke vectors. This character would require 48 byles if stored as 
iiorrua] long vectors — 12 X and 12 Y' values each two byles long. 

or 33 MHz. Ore -byte accesses to an accessor^' card require 
a minimum of three BCLKs or approximately 375 ns. Tvvo-bjle 
accesses require a minii^iiim of six BCLKs or approximately 
750 ns. If the accessory iioard is not ready to start a cy<4e 
when it is accessed, or if the access takes longer tiian the 
minim iim, additional wait states of one BCLK each are hi- 
serted. bi Fig. 3 the signal BALE (bus addiess latch enable) 
signifies the start of a processor cycle and that the address 
on the bus is vaMd. Read/write (R/W)) and niemory-I/0 (M-l/0) 
are control signals indicating Llie diiectioii and source or 
destiiiation of the data on the bus. The read and write data 
signals indicate vvhen the data tiiust be stable for either type 
of transfer. 
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Fig. 3- A i>i>ital sts-SCtJC ISA cycle. 



Tlie HP Utra VGA board is implemented as a 16-bit ISA ac- 
cessory board. Because of this, its performance is limited by 
the bus bandwidth. F'or exami^le. transfening a wotd from 
one location to another takes a minimum of six BCLKs (750 
ns) even tJiough the memory is capable of 80-ns access time. 
Tlie I LP Vectra 48(=> mul 4B()/33T computers have an EISA 
biLS, but the addiTioruil iost of implementing the I Htra VGA 
boiird as an EISA peripheral was not justified since it could 
not take ad\^ajttage of tlie advanc ed features of the EISA bus 
such as bus juiistering. Also, being an ISA b( jard allows it to 
be used in other IIP computers such as the Vectra RS 25/0^ 
which doesn't have an EISA bus. 

In the Vectra 48tVlJ, the video subsystem is not a plug-in 
accessory board but is embedded on the processor PC 
board. It is connected directly to the host bus and Ihiis can 
take advantage of the 32-bit bus width and the fast ch>ck 
speed. The chipset used in the HP Vectra 486/11 allows for 
four separate buses: the local bus, tJit^ host bus, the EISA/ 
ISA bus, and the |>eripheral bus (see Fig, 4j. The Intel4Bfi 
processor ami tlte secondary cache menioiy directly inter- 
face with the lot ill (>us. This bus architecture is tuikiue tn 
the Vectra 48i5/Li. In most lntel4iS(j designs, what we refer to 
as the host bus is tlie local bus atid the cache shares bus 
bandwidth witii other elements of the system. The HP 4S6/LT 
gains perft)rmarice by sepai"ating thc^ local bus from lire host 
bus since most high-speed critical operations are processor 
atX'esses to die cache. Tliis also allows simultatieous act- ess 
to main memory or mass storage by intelligent peripherals 
without interfering witii the CPU. 

The host bus is a 32-bit bus, operating at the Intel486 clock 
speed, which connects the main subsystems of the |>mcessor. 
As shown in Pig. 4t these sutjsysteiiis inchule the niemoiy 
controller tlie EISA/ISA bus ct^iitroller, I lie peripheral con- 
I roller, and the video controllei; The KLSA/ISA bus is the 
backplatie bus used for plug-in accessory- cards. The periph- 
eral bus connects matiy of the onboai d subsystems in an ISA 
style protocol. 

Devices on the host bus receive the signal HADS (host ad- 
dress data strol>e) to begin a cycle (see Fig. 5). Tliis causes 
an address decode to take place in the de\1ce. If the de\ice 
recognizes the address as its ov^ti, it responds by asserting 
the signal tHLAC (host local access). This causes other devices 
on the host bus to remain quiescent for tiie duration of the 
bus cycle. If no de\ice responds, the address is propagated 
onto the EISA/ISA and peripheral buses. When the respond- 
ing host bus device compk^tes its operation, it responds by 
asserting the signal HRDY (host ready) which ends the cycle. 

By comparing the liming diagnuns shown in Figs. 3 and 5, it 
can be seen diat the host lius implementation eaii speed up 
indKldual I/O or nienioiy cycles by a factor of four to six. 
The decrease in CPL'-to-peripheral transfer tune and the 
accelerator built into the chip (described below) contribute 
to the superior performance of the embedded fiftra VGA 
subsystem, 

VRAM versus DRAM 

Most PC \1deo adapters use standard dynamic RAM (DRAM) 
for display memoi^'. \^Tiile this is a cost-effective solution, it 
leads to peiformance penalties. Because a DRj\M Itas a single 
data poit, accesses from the CPL^ and the display controller 
must be time-multiplexed. The display com roller must have 



34 



,] I n IP UB'ri [ te w let t -Pac kard J ounml 



)Copr. 1949-1998 Hewlett-Packard Co. 




Coprocessor 



Local Bus 





Memory 
Contr fitter 



UllfaVGA 
Video Suh5¥Si&«i 



Host Bus 



EISA/fSA 
Comroller 



Coftlrotler 



Penpherai 
Bus 





CMOS 


Flash 


Nonvolatile 


SIOSHOM 


RAM 



EISA/ISA Btis 



Serial 1 



Parallel 



Kevb^ard 



Serial 2 



Mou&e 



Flexible Oisk 
Centroller 



IDE 

Hsfd Disk 

Controller 



Fig* 4* Brisic tilock diagrain of the 
HP VecT,rd 4S6AJ. 



a high priority because any missing data would show up as 
noise or snow on the display. In the original CGA, the only 
time tlie CPU is allowed to access dis[>tay memor>' is during 
the retrace inlenab at tlie end of each scan line. Tiiis means 
thai that the CPU caii get only nvo or three clean accesses 
every 63 fjs (see Fig. 6a}; 

Tlie EGA and VGA Jirchitectiu'es also use DRAM, hut. hy using 
tour-hit wide chips, the CPlI/(list)lay interleave is brought 
down to 1:2 (see Fig, 6b), Tliis dlows a CPU access every 
450 ns. This still necessitates slowing tbe CPIT down, since if 
the access just misses, the processor has to wait 450 as until 
the next accesjj window opens. 

Another RMI architecture ntade especially for video use is 
the video Rj\M 0' RAJVl). VRAM is a dual-ported de\ice that 
allows the CPU almost unlimited access tr> the display mem- 
Oiy while still maintaining a noise-free display Fig. 7 shows 
a simplified drawing of a 256-bit V'RAJM The RMI array ui 
this case is 16 rows of cells by 16 colunms. hi an actual 
VRAM the array would be 64K bytes in a 256-by-256 array. 

In normal DRj\M accesses, a row Ls selected by the row ad- 
diess and read ui lo the sense amplUlem. Tlie colmmi address 



is used to select one of the colimin sense aniphfiers to read 
or write a single bit of the array 

In a VRAM, access to a row is also selected by the row ad- 
dress. However, instead of only one colunui being selected, 
all of the calimuis are simulraneously read into a serial sivift 
re^ster. The data is then shifted out of the shift register as it 
is needed by the display. In this way the display controller 
need only lock out the CPU for one cycle out of every 256 
(or less depending on the widtli of the VRAMs) to present a 
clean display. 

The Ultra Vt tA boaj-d uses the VRMI mfide when it is oper- 
ating in its enhanced nujde. hi the standard V(;A mode of 
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Fig, 6- CPU/dispiay memory' accesses, (a) In ihv nriginal (XJA imple- 
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ilip E(iA ami VGA architectures thf* CPU gets act^es*^ to meiiU3ry one 
out of f'vr'iy^ two nicnior>' cycles. 



Fig. G. Ty|>ira! In>st Inm tyvlp. 



.)imr nm lIpwlotT'F'at karit Juuinal 35 



)Copr. 1949-1998 Hewlett-Packard Co. 



Doi Clock 
Shift/Laid 



Serial Sitirt Regi$lfir 



Sefial 
Dal? Pon 





A 


A a 


A 


M 


ii ii 


A 


a 


ik 


A 


A 


4i 


A 


A 

1 


A 




How 
Solector 












































































































































































Row 






























; 




Aifdress 














































































































































































































































































































, 






uiiiitmiimi 




Column 


Column Sense Amplrfiors 

1R-1 rnriiitin MtMllinlMvar 
























■IP, 















Dynafnic 
RAM 
Affoy 



DRAM 
W Dala Port 



Fig. 7. Simplified dia^imm o( ii 

VRAM. 



operation the I'ltra V(fA firyard arcesses vkleo iiieninry as ir 
it were DRAM. 

Clock Synthesizer 

Because of the many differenl cUsplay resolutions and moni- 
tor characteristics associated with (lie Ultra VGA board, up 
to 16 differenl video do( t lork frequencies are needed. The 
board space needed wouitl be prohibitive if tliese clocks 
were generated witli discrete cr>'.stals or oscillators. Instead 
we use a cloclc synthesizer If. This relatively new chip 
combines analog and digital circuitry on the same chip. It 
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Analog Outputs Id MonilDr 
Fig. 8. Simplified diagram of a R.\MDAC. 



contains an oscillator, a phase-locked loop, and tligital divid- 
ers that diive the phase-locked loop. Except for the refer- 
ence frequency crystal ( 14.'31818 MHz) and an RC filler, all 
of the nc^cessary components are contained on the chip. 
This gives enormous capability in very little board space. 

RAMDACs 

The C'GA runs its monitor with four digital signal lines: red, 
green, bhie, and intenshy. This allows a maximum of 16 
colters It) he tlisplayed. In graphics modes the colors are 
fixed by the hardware and selected from two palettes of 
four colors each. 

Tl\e EGA extends this by pro\ading six digital signals: red, 
red', green, gteen'. blue, and blue'. ThLs allows a miLximum 
of 64 different colors to be displayed. The digital-to-aniilog 
converters (ElACs ) aie built into the monitor and the 61 
shades are fixed by the manufacturer. The EGA board has a 
palette consisting of 16 six-bit entries, ^md t^ach palette 
entry can be progranmied to select one out of 64 shades. 

The VGA doesn't drive the monitor with <iigital signals, but 
uses analog signals instead* one for each primary color (red, 
green, and l>kie). By varying these sigtKils, iu\ almost infinite 
r:iiige (jf colors can he displayed. The standard VGA uses a 
KAMDAC Willi 2r^6 eighteen-bit entries. Each of the entries 
has six hits eacii for red, blue, and green (see Fig. S). The 
maximum number of colors that can be generated is 2^'^ or 
262,144, Of these, any 256 ctin be displayed simultaiieously. 

Ergonomics in PC Grapliics 

Higher Resolutions and Higlier Refresh Rates 

Since the establishineni of the IBM VGA as a PG graphics 
standard, there has been steady progress in the develop- 
ment of higher screen resolutions. Tlie IBM VGA offers a 
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maximum resolution of 640 hy -ISO pixels witli 16 colors. 
Recent super-\'GA h>oards from various manufacturers sup- 
port higher resolutions of 800 by 600 and 1(^4 by 768 pixels, 
along wiih 256 colors. 

The most direct benefit of higher screen resolution is a lariger 
display area tor the user Tliis translates to advantages such 
as the ability lo dts^ilay more mws and columns of a spread- 
sheet, or larger sections of a word processor document. 

The display refresh rate has also been steadily improved to 
address the problem of screen flicker Flicker Ls perceived 
by the user as a direct result of the monitor screen not being 
refreshed at an adequate rate. Since all PC monitors are 
based on catliode ray tube (CRT) lechnolog^^ tlve contents of 
the sc_reen are ncjt static but are constantly being swept onto 
the screen phosphor on a hne-by-line basis. If tlie graphicts 
system does not support an adequate screen refresh rate, 
pixel intensity' will have time to decrease between successive 
refresh cycles, resulting in the perception of rapid screen 
niishii^, or flicken Viewing a monitor screen vntli significant 
flicker, especially for long periods of time, can result in eye- 
stniin ;md other health hazards. The recent imprf>\ enient in 
scTeon refresh rates has been largely successful in reducing 
the problems associated with screen flicker. 

The standard VGA implements a screen refresh rate of 70 Hz 
for all text and grapliics modes, except for ^540 by 480 graph- 
ics modes, which offer a 6frHz rate. The Video Electronics 
Standards Association fV^SA) provides standards for re- 
fresh rates at higher resolutions intiiiding 72 Hz for 800 by 
600 resolution and 70 Hz for 1024 by 768 resolution. 

Monitors 

Increasing the screen resohition or the refresh rate will 
directly increjtse the graphics output horizoiual scan rate 
(ils^iic), a nteasnre of the time between successive horizon- 
Uil display lines on the screen, Thc^ standard VGA tises a fixed 



Hsync rate of 3L5 kHz for aK text and ^aphics modes. Com- 
binations of higher resokitions antl higher refresh rates can 
yield an Hsjtic rale ranging from 31.5 kHz to l>eyond (U kHz, 

All standard VGA-only analog monitors on the market can 

support only the standard 31.5-kHz Hsync rate. To properly 
support modes with ttigher Hsync raies. duai-s>Tic nr multi- 
sjTic monitors are rettuired- Dual-s>iic monitors, such as the 
HP SuperVGA Display (HP D1194A) and the HP Ergcmomic 
Super VGA Display (KP TiUOoA), can support Hsyiw rates 
otlier than 31.5 KHz. Tlie capabilities of these two monitors 
and others are listt^d in Fig. 9. 

AInltisj'nc monitois are typically capable of synchronizing to 
a continuous range of Hsync frequencies, allowing them to 
support standard VGA modes as well as higher resolutions. 
The HP Lltra VGA Display (HP D1193A) is an exiimple of a 
m u Itisync moni t or. 

The HPUVGA Utility 

Willi the choice of multiple refresh rates ^md monitors with 
different resolutions, the user tieeds to configure the graphics 
system to seleti Ihe coiTect refresh rates for the resolutions 
suppoHed by a given moniton llie HP ITltra VGA l>()ard is 
shipped with a configiu-ation utility called HPUVGA.EXE, which 
allows the u-ser to customize the Ultra VGA board oiiipiif to 
imy HP PC graphics monitor. 

Embeddetl within the HPUVGA utility is infomiation pertain- 
ing to the synchronization capabilities of all of HPs PC* 
graphics monitors. By correctly selecting the monitor in use, 
the user is able to view the refresh rates supported by the 
momtor at grat>hlcal resolutions of IHO by 480, 800 liy mi 
and 1024 by 7(i8 pixels. In cases in which the mtjuitor can 
support two or rtiore refresh rates foj- a given resolution, the 
user is given a choice. All refresh settings are saved in an HP 
CMOS \ideo byte, which is described later. 
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D1192A— HP McjiDchrofne Display 
D11S7A— HP 20 Inch High-Resorulinn Oisptay 
Dt193A-HP Ulna VGA 17 Inch Display 
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The HPUVGA ritility also sitpport:s emulation modes for the 
MDA, 1 iGC\ and CGA PC graphics staiKl^irds, Tvto additional 
132-colimin text modes^ with 25 aiid 43 rows respectively, 
can also be set \ia the HPUVGA utility. 

HP CMOS Video Byte 

Ri^tn^sti ratt^ sc^ttings for graphics resoiutioiis of 640 by 480, 
800 by 600, and 1024 by 7G8 pbcels ai^e saved in tJie HP CMOS 
video byte. The assignnients for each bit in tins byte are: 

Bit 7: Alternate I/O port select 

Bit ix [leserved 

Bits 4 and 5: 1024 by 768 I'efresh timing 

Bits 2 and 3: 8(^0 by 600 refresh timing 

Bits and 1: 640 by 480 refresh timing 

T3ie monitor timings for all supported video modes are 
stored iji talile fomiat in the video BIOS, with one table 
trnlry per video mode. Wlien ;m ai>pheation calls ihe tnt lOh 
se^tnode tunctioji of the video BIOS to enter a speeific ac- 
celerated grapiiics mode, the video BIOS accesses the HP 
CMOS video byte to determine the refresh rate currently 
selected, then uses the (corresponding li mi jig table lo get the 
correct refiesh rate. This scheme allows tiie refresli rale 
control to be apphcation independent. 

Since HP CMOS memory is a nonvolatile system resource, 
the refresh rate settings are presented in tbe same way as 
other standmd system configuration iufomialion. This 
scheme is capable of support ing operating systems besides 
MS-DOS-. Alternatives to IIP CJMOS memory for saving re- 
fresh rate settings have been carefully eotisidered. Adding 
EEPROM hardware to the HP Cltra VGA board to store fhe 
refresh rates had the disadvantages of high cost an<l hi- 
creased design complexity, losing a TSR program (menior>' 
resident software) to preserve the refresh rates would have 
wt irked onJy for MS-DOS, and ottier systems such as tbe OS/2 
and I^NIX"^ operating systems wouki also require specific 
memo 17 resident softwai'e. Memory' resident softw^are woiiid 
occupy valuable system memory and reduce ease of use. 

Display Drivers 

A display driver is a distinct program module that is made 
up of a gi'oup of display functions that provide a standard 
interface between an apphcation and a particular type of 
video display hardwajT. 

The HP Ultra VGA accessor^' card provides many features, 
such as hardware line drawing, bit -block image transfer 
(BitBlt), rectangle ti]\, cUKi hardware clipping. However, 
these featiaes caji <mly he accessed through some special 
video enhanced modes which me unique to the grapliics 
processor in the IIP Ultra VGA card. In most cases, applica- 
tion progiams, such as Microsoft Windows and AutoCAD, do 
not know (and do not want to know) Ucnv to enter these 
enhanced modes. It is the nianuracturer-specific display 
dri\ ei' t hai lets the application program take fuU advantage 
of tlie graphics processor. 

For examplCt to make the HP Ultra \^GA caid work in 
256-color enhanced mode with i024-hy-768-pixel resolution » 
a disT^lay driver htis to call the BIOS interrupt lOh with regis- 
ter's AX=0x4F02 and BX=0x2O5- hi general, to set the display in 



one of the HP Ultra VGA enhanced video modes, the driver 
calls BIOS interrupt lOh with the AX and BX registers set to 
values that represent different resolutions and colors. 

To access haidware line drawing, BitBlt, and rectangle till 
features of the MP I lltra VGA hardware, the display driver 
sets the drawing command register at I/O address 9AE3h. 
Fig. 10 shows a definition of each bit in this register. 

For examiile, when hj\ aijplicaiif>n wants to draw a line on 
die screen, llie display driver sets the following bits in die 
drawing command re^ster at VO address 3AE8h: 



Bits 


Setting 


Meaning 


1:M5 


001 


Draw Line Command 


04 


1 


Draw = Yes 


00 


1 


Write 



The driver also tias to find out the tlrawing direction to fill in 
bits 5 tf> 7. 

.^not her important feature of the HP Ultra VGA card is the 
short stioke vector di^awing ability, losing short vectors for 
disj J laying text in tlie grapliics mode improves \ideo perfor- 
mance. UTien an application program requests to display 
text on a high-resolution grapliics screen, the <lisplay tlriver 
.sets the sl\ort stroke vector conmiand register at the 1/0 
address 9EEB11. Fig, 2b shov^^s the bit definitions for the short 
stroke vector register. 

TVl)icaIly, an application progjam uses a standai-d interface to 
tlie display so it dcrt^sn't have to be concerned with the type 
of hardwaie itistalled on the machine in which it is running. 
This ist^lates the a f>pli cation piogram from the display hard- 
ware. For example, most Windows applications are written 
without regard to tlie t^pe of video adapter used, instead, tJte 
programs are wiitten to interface witli Microsf >ft Windows. 
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Fifi. 10. IKHnitiDrts of f?aeh bit in the drawiii^ conuiiand register. 
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Fig, 11. Software hierarchy from the application to tJie display dm^en 

The video adapter's display driver takes care of writing to 
the display hfirdware. Tlie Windows display driver works 
with ajiy Windows pragram. By gobig thiough a stimdiird 
interface, die display driver developer- and the a|>ijiifation 
program developer art; Isolated from each other (see Fig. 11 J. 

The Windows Display Driver 

The display drivi^i^ tVir Windcjws is a dyiiairiic link library that 
c^onsists of a set, of graph it-s functions for the IIP Ultra VGA 
display card, Tliese funcl.ion!5 translate device independent 
graphics eonunaruls from the Uindows graphic^ device inter- 
face (GDI) intcj tlie connnajids (such as the drawing coni- 
niand desc ribetl above) and atlions the Titra VGA graphics 
engine needs to rlraw graphics on the screen. These functions 
also give information to Winflows and Windows applications 
about color resolution, scieen size imd resolution, graphics 
capabiMtics, imd other ad Vcinced features, su<'h ds LlitBlt, 
line-ttrawing, polygon till, and liarilware cursor support. 
Applications use this information to create the desired 
scTeen output. 

llie HP L'ltra VGA Windows display driver Is based on the 
sample driver for the IBM 8514 graphics adapter The source 
(*ode IVjr the 8514 dn\er is axailable from Microsoft's Driver 
Development Kit, Like most Windows tiisplay drivers, tlie 
Ultra VGA driver ijrovides the following basic functions: 

' Output. Draws various shapes. 

I Enable, Starts or resumes display activity. 
Disable. Stops display activity. 

ReaJizeObject Creates physical objects (e.g., pens, brushes, 
mui device fonts) for exclusive use by Ihe display driver 
This is where rive translation between device itKlepeiulent 
(or logicalj iind device-optimal (or physical) objects takes 
place. 



• Colorlnfo. TVanslates between Ic^cal colors, which are 

passed by W^mtlow^s as double word RGB values, and physi- 
cal colors recognized and used by the ritra VGA di^lay 
drivers, 

• BitBli Supports bit-block transfers by copying a rectanguJar 
block of bits from bitmap to bitmap while appl>ing some 
si)ecified logical operations to the source and destination 
bits, A bitntap is a matrix of memory bits thai defines the 
color and pattern of a corresponding matrix of pixels on the 
device's display screen. Bitmaps provide the ability to pre- 
pare an image in memor>^ and then quickly copy it to the 
display. 

• BctTiKtOyi. Draws a string of characters at a specified loca- 
tion on the screen and clips any portion of a character that 
extends beyond a bomiding box of the string, 

• StrBIt Supports text drawing for the earher versions of 
Windows. (It just makes a call to ExtTextOut.) 

• ControL Passes special control information to or receives 
special information from the Ultra VGA display driver. 

Besides the functions listed above, the following features 
have been added to take fuh advantage of Hie graphics engine 
m the Ultra VGA. 

• Different Resohitions. Separate display drivers iire pro\idecJ 
to support resolutions of 1024 by 7G8. 800 by 600, and (J40 
by 480 pixels witli 256 coloi^. 

• Hardware Cursor. An onboard hardw^u-e cuj^sor ( t.>4 by 64 
pixels) for fasi: ciu^or movement in the enhanced mode. 

• Fast Polyline Draw. Onboard hardwaie is used to draw solid 
polylines at a very fast speed, 

• Polygonal Capabilities, An onboard drawing command 
register and hardware are used for quick rectangle fill and 
scanline drawing, 

• Past Rectangular- CMipping. Rectangular clipping is pro\ided 
via a clippitrg window boundary register and hardware that 
tliscai'ds pcjints that are outside of a specified rectangle or 
region tlrawn on the screen. 

• High-Speed BitBlt. Onboard har'dware is usetl for high- 
perfonnance bitmap image transfer ojrerat itins, 

• Fa St Border Funcri(jn. A function that draws borders for 
windows antl diaJ(jg boxes very quickly. 

• Save Si-reen riiUnai>. The SaveScreenBFtmsp funtllon aUows 
Windows to save Ijirmaps temportuily in otTscreen video 
memory. Tliis ftnrction speeds the drawuig ot^erai U>ns thai 
require restoring a portion of the screerr ihai was previously 
overwritten. 

• Support for Liuge Forrts. Sujjport for large fonts is provided 
in which the forrr and glyph information can exceed 64 K 
h>tes. 

• DlBs Support. This ftnrction converis device independent 
bitmaps (DlEis) io physical format for direct trairsfer to the 
display without applying a raster operation. Note that a DIB 
is a color bitnrap in a format that eliminates the problems 
that occur when transferring device rlependent bitmaps to 
tlevices having differeirce bitmap formats, 

• Stipport Device Bitnrap. A device bitnrap is iury bitmap 
whose bitirrap bits are stored in device menrory (sucli as 
RAM on a display adapter) instead of main nrenror>'. Device 
bitmaps can signincani ly increase the |)erfurinam*e of a 
graphics driver and free system memory for other uses. 
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• Font Caching. Font caching is lemjKirarjly taxing Ihe most 
recently uscfl fonts in ijfllscreen vitlet> memory; TliLs riiru'lion 
speeds np text -redisplaying operations. 

• Small mul Large Fonts. Tlie Ultra VC rA display driver prf>- 
vides both small and large fonls in the 1024-by'76S high- 
resolution mode, 

• Vector F'onts. The Ultra VGA display ri river supports vector 
fonts, A vector font is a set fjf gl>]>h definitions, t^Hcli i'on- 
taining a setiuence of points retjresentjng die st;irt and end 
points of the Une segnients Utat define ttte appearance of a 
character in a particuiar font. 

Working Together 

The functions in the t If ra VGA dis(>lay driver ajid the Win- 
dows graphical device interface (GUI) vtork together to 
make efficierU use of tiie features provideti in the HP Ultra 
VCiA board. The rest of this section describes how these two 
entities work together 1o initialize die display and peiform 
some simple graphical operations. 

When the user types WIN to start Windows, a small program 
WIN.COM determines the mode in which Windows is to nm. 
If it cieterinines that it Ciin run in the enhanced mode, Win- 
dows nins KRNL386-EXE { via W1N386.EXE). WJnle inilializing, 
Windows ciiecks the DISPU^Y.DRV seHing in the SVSTEM.INI file 
to deternhne the file naine of the display driver to load. The 
HPUxxx.DRV driver modules me the display drivers for differ- 
eni resolutions mxd video memoir configurations. The 
Windows graphical device intciface (GDI) then calls the 
selected display driver's initialization rout hie. 

During tnitiaiiijation, the Windows GDI makes two calls to 
the Enable function in the Ultra VGA display diiver. After the 
first call the Enable function then returns to the GDI the 
laDifNFO data structure, wiiitdi describes the general physical 
characteristics artrl capabilities of tJie HP lltra VGA graph- 
ics engine. The GDI uses diis Liilbnnation to determine what 
the Ultra VGA chsplay driver can do and w^hat the GDI must 
simulate. 

Tl^e second time die GDI makes a call to the Enable function, 
tile display driver does tlu'ce tilings. Fust, it mitializes (he 
Ultra V(tA graphics enghie to be ready to run Windows, This 
includes saving the c undent mofle, usmg the videt) BIDS func- 
tion lOh calls to set ttie enlianced display mode tuul colors, 
load the p^dette, jmd so on. Next, the Enable function calls the 
hook_mt_2Fh fmiction in Uie display dj iver s<j that each call to 
internipt 2Fh will be checked to detect any screen Switch 
function calls. This is because in a preomplKe multitasking 
environment such as 386-enhan red- mode Windfjws, the dis- 
play driver has to save and restore the display hardware 
sett ings. such as video mode ajul register data, whenever 
Windows is clumged between a Windows api>ltcation and a 
non- Win d o ws a pp 1 icati on . 

The last thing the Enable function does is lo initialize juid 
copy ihe PDEVICE data struct iu*e. The PDEVICE ttala stnictnre 
defines ]ihysical objects ratlier dian bitmat>s. Pliysical ob- 
jects define the attributes (such as color, wifith, and style) of 
lines, patterns, and characters drawn by the display driver. 



Physical objects corresijond to the logical pens (used to draw 
polyhnes and borders around objects drawn by the Output 
function), brushes (usefl to fill tigures drawn by the Output 
fmiction and to lilt rectangular areas created by the BitBii 
function), ^md fonts (used by the ExtTextOut function to draw- 
text). Physical objects also contain f'ltra VGA hardware 
device dependent infonnation that a f lisp lay driver needs lo 
generate outtHit. These physical objects are created by tlie 
RealizeObject function. 

After the RealizeObject fimction is fmished creating the default 
pens and bnishes for Window^s and the brushes needed to 
draw the desktojj and fill the Prt>gra]n Manager window, the 
BitBIt and ExtTextOut fimctions are called to do all ihe drawing 
on die screen. First, the BitBIt function rhaws a rectangle on 
the scrt^en with the background color by using a pattern 
copy operation. Next, the BitBIt function is called to draw 
some borders and rectangles. Fu^ally, to complete display 
initialization all the icons, text, and pictures aie put on the 
Wnuiows screen by using fimctions such as BitBtt, ExiTextOut^ 
and the brushes created by the RealizeObject function. 

\\Tien a Window^s applicarion requests to draw a line on 
the screen, the GDI cheeks the dpLines entiy in the GDlllMFO 
structure, wliich was filled by the display driver during ini- 
tialization, to see if the display driver supporis line drawing. 
Since the I -lira VGA driver supjjorts haidware line drawing, 
the GDI calls Ihe Output function to ciraw a line on tlie screen- 
Othei'wise, ihe tiDl has to shiiulate line drawling by coinbui- 
ing scan lines and t>oly lines. 

If a W'indow s apphcation asks to display text on tlie screen, 
the GDI calls the ExtTextOut funeiitat in tlie display driver Tlie 
ExtTextOut function receives a string olcliai-afler values, a 
count of the charac lei's in the suing, a stalling j position, a 
physical font, and a DRAWMQDE suijcture. These values aie 
used to create ihe intlividual glyph images on the screen. 

Finally, when a user asks to quit Windows, the GDI calls the 
Disable function In the display driver This function frees any 
resources associated with \he jihysical device and restores 
the I Itra \'(JA h;irdwai'e to the state it w^as m before Wmdows 
stalled. After the display driver returns from the Disable func- 
Xkmr the GDI frees the memory it allocated for the PDEVICE 
strufture and frees the display driver, removing any driver 
code and data from niemoiy. 
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POSIX Interface for MPE/iX 



Differences in directory structure, file naming Gonventions, and security 
were among the areas in which mechanisms had to be developed to 
enable the POSIX and MPE XI interfaces to coexist on one operating 
system. 

By Rajesh Lai wan! 



Tile IEEE sUmdard for a Portable Operalirig System Interface, 
or POSIX. defines a standaj'd operating system ititerface and 
en\irORnieni to support soiiree level application portability. 
POSLX specifies the fimctions and scniees an operating sys- 
tem must support and the application progi-amnmig interface 
to these sendees and functions. 

POSIX 1003.1, which defines a standard set of progianmiatic 
interfaces for basic operating system faciJities, and POSIX 
1003.2, which specifies an interatlive interface that provides 
a shell and utUities similai" to those provided by the UNIX* 
operating system (see Fig. 1), ;ire integrated in the MPE XL 
operating s>^stem to form t±ie MPE/iX operating system, 
which runs on the HP 3000 Series 000 system. 

The prograJTimatic interface and directory^ structure of 
POSLX 1003.1 allow MPE/iX users to use POSIX functional- 
ity without atiy impact on existing IIP 3000 applications. 
Moreover, MPEt applications are able to access POSIX files, 
and POSIX applications iu-e able to access MPH files. Thus, 
MFE/iX provides interoi>erability and integration between 
MPE and POSIX applic ations and data. 

t From hste an MPE vviN be used to refer to the MPE XI version of ihs MPE Qperating systefn. 
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POaBE is Significantly different from MPE in a number of 
technical areas such as director>' structure, file system, se- 
curity, user identificadon, file naming, proceSvS management, 
and signals. In the stmimer of 1991X a POSIX architecture 
teant was fonned to look at these differences and to archi- 
tect a way m which MPE and POSIX could coexist on IIP 
3000 Series 900 systems. 

Despite the differences between MPE and POSIX concepts, 
the team had no problem visualizing MPE and POSIX as one 
operatuig system. To achieve a successful iniegration of 
POSIX ajul MPE, several stumhhitg blocks had to be over- 
come. This paper describes the t^roblems encountered in 
merging POSIX ajvd MPE m tliree n\i\}or leclmicaJ areas: 
directory structure, Hie naming, and security. The paper 
also describes the ahernatives rejected by the POSIX 
architecture team. 

Directory Structure 

MPE has a O.ved, ttuee-level directory structure. In this 
model, tlie direriory tree consists of one or more arcoiuits- 
Each a* t'CJiint ifintains one or more groups and each group 
has zero or more files in h (see Fig. 2). On die other hiuid. 
POSIX supports the notion of a hienirchical directory stnic- 
ture. Fig. 3 shows a typical POSfX directory. Some of tlie 
features that FHJSIX tt^iuires ui a dire<'i<)iy stnictiire mclude: 
Supi>oi1 for the and , enlries upon creation of a directory 
Support for a tnie hieraichicat dire<'tor>' vtilh file names of at 
least 14 characters aiid path names of al least 255 characters 
Snpt>ort f<jr the POSIX rule for djrettoiy deletion, fiiat is, 
the director>' must not contain ;iny entries other than . and . 
foj the unlmk of a directoiy to succeed. 
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Fig. 3. A tvpiral POHIX directory. 

MPE groups and accounts are different fram tfie I^OSIX 
directories because of the specid inrorniatiou contained in 
thoriL To integrate the POSIX and MPE directoiy structures 
successfully, wv tiad to consider removing this special infor- 
mation from MFE groups imd accounts to acconmiodale the 
new diiectoiy structure. The follov^ing hsts some of tliis 
special infonnation. 

• On MPE, accounts aie useci to manage col Unctions of usere 
for file sliai'ing. Each MPE accoLmt entiy contains a pohiter 
to a list of users that mf members of that at count. 

• MPE groups and accounts keep track of Uiiee resources: 
disk space, connect time, and CPU tinie. 

• MPE groups and accounts contain security information that 
is used to evaluate pennission to access certain fdes. 

One of the cliallenges for tlie arclutecture team in mtegrating 
the hierajxhicai directory of POSIX with tlie MPE durectory 
structure was to make the directory generic enough so that 
future standai'ds could be suppoited and the accounting antl 
user identificatif)!! fmictions could be removed from the 
directory in the long temi. Tliese efforts resuiteii in the di- 
nectory shown in Fig, 4. 

Conceptually, the new tU rectory stnictuie is just a tr'ee 
stnictuie (a directed acyclic graph, to be more pn*cise). The 
root of this tree is designated by slash {/). Tlie root may have 
files ajid directories uniier it. Each directory may havc^ files 
and tiireciories under it. There is no arctiitecturaJ limitation 
on the depth of the directory tree. 

The ordy restriction on the directoiy structure lias to do 
with the MPE gioups iuid accounts. MPE accounts can only 
exist as unmediate descenthuils of the root directoiy and 
MPE groups can only exist as iounediate descentkints of 
MPE accoimts, Tliis means that altliougli files ^md directories 
can be placed an>T^^here, MPE directory objects (groups aiid 
accounts) are restricted to their conventiontd locations- 



Accounts and groups are distinguished fi^om POSIX files and 
dlret tories based iipon how llu^y ar(* created. An account is 
a directory that is (Teated by lh<^ NEWACCT cr:)nunaiid and 
inirged via tlie :PURGEACCT couunand. Similarly, a group is a 
directory ttiaf is creared by tiie NEWGROUP commtmd mid 
purged with the :PURGEGROUP <jr PURGEACCT commands. 

In the new directory structure all users are registered in the 
III) (user i< lent i Her) datahast^ required Ijy POSIX, and the 
rciru[)inaiioii (jf tlie IIU and GID (gmup ideniifier) data- 
bases replaces most of the information formerly held in the 
MPE account and user directory nodes. 

Rejected Directory Designs 

In the beginning the architecture team considered Ihe idea 
of a du£il-root directory^ stmcture. Fig* 5 shows an example 
of this idea. In this scheme, a directory called MPEXL wouki 
exist flirectly below the joot of the hierarcliictil directory. 
Tins directory woultl be the root of the MPE chreclory^ von- 
t^iniJig all the accounts, groups, and files. Linderlying this 
proposal was the assumption that die MPE envuonment 
would t\ot he t hanged. Factors motivating this proposal 
were the desire to maintain compatibility with existing ap- 
IiUcations, to elimmate tlie need to modify existing directory 
services, anil to isolate the POSIX hiennchical diiectory 
services froju having to interact with MPE direetory' slmc- 
tmes. This idea wtis rt^ecterl by the architecture temn for 
several reasor^s. First, this wouki make tlie hierarchical di- 
rectory nonmiifomu The MPEXt directory (shown in Fig. 5) 
and all its descendants would not follow the normal hierar- 
chical diretnory^ rules, ami applications would have tcj make 
exceptions for thenr Secotul, this would prevent users from 
incoriJotating the hieraichical directory into their cunent 
environment. Finally, this prot>osal was not in line with the 
long-term goal of making all the directory objects in the 
system one type. 

Another idea was to use the same dual-root stnicture but 
not extenialii^e tlie fact. With this idea, tlie direc^tory ser- 
vices would deterniine which of the two roots to use when 
searching for a paiticulai' name, and duplicate entries would 
not be allowed in the two roots. Thus, for the direcloiy 
shown in Fig. 5, a name like Ct. PUB. SYS woidd only refer to 
Ct PUB, SYS m the MPE duectorj; and a POSIX iiUeiface would 
rmt be able to create a directt;>r>' /SYS, While this so hit ion 
solved some of the problems with the pie\ioiis alternative, it 
still had some problems. For example, Ihe fUrectoty ser\ices 
w^ould have to do an extra search just to determine w liich 
root to use, thus affecting peiformance. More important, 
MPE and POSIX directories %vuu id not have been integrated. 
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Fig. 5. A dire<!toi>' stnicture that 
was rejectefJ for MPE/iX. 



File Naming 

In designing the file naming rules, the main objective was 
that the existing MPE interfaces such tt^ MPE intrinsics and 
command inlerpreter (CI) conimamls shoaki he able to refer 
to all objects in the same way tJiey did before MFE/'iX. The 
familiar MPE tjbjects can be refened to by using the syntax 
for file names file. group. a ccount. file.grnLp. or file. The entire file 
name is first upshifted by the MPE name senej , For exam- 
ple, if ttie file name is prgfiiepx. develop, the MPE n<ime server 
refeiB to the file PRGRLE in group PX in account DEVEtOR Simi- 
Jarly, if tlie file najue is. say, prgfife.px, it refers to the file 
PRGFItE ill group PX in the logon accoimt. Finally, if the file 
name is fully unqualified (no group or accomit), say, prgfile, it 
refers to the file PRGFILE in the current working directory 
(CWD). ^Tien a user logs on, the CWD is the same as the 
user's logon group. So unleas the user has exphcitly changed 
the CWB, a fully miqualined file name such as prgfile contin- 
ues to refer to the same object as before MPE/iX (e.g., file 
PRGRLE in logon gi'onp PX.DEVELOP). 

The file named dawn^^foad in Fig. 4 cannot be referenced 
through the MPE name serv er because tlie file is not in an 
MPE group and it doesn't have a valid MPE file nmne. The file 
name must somehf jw esc aije b(^ing jjrocessed by the MF^E 
name servx^r so that it Ckm be processed by the PCJSLX name 
server. Tliis is done by using I tie chtu^acters . or / at tlie begin- 
ning of a file name. For file uaiues beginning with . or/, the 
MPE name sender does noi iipshit> tlie name, but passes h to 
the POSIX name server Tlierefore, the file down_lo3d in Fig. 4 
can be referred to by using the name /users/ieff/bin/down_ioact 
(the complete path name). Alternately, if the ('WD has been 
chiuiged to /users/jetf, die file can also lie referred to by the 
name . /bm/down_(osd. Fig. (i illustiales the MPE name serv^er 
rules for MPE and POSIX tile names. 
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Ttie name server used by POSIX 1003.1 fimcdons and POSIX 
1003.2 commands is the POSIX name sender. However, MPE 
inteifaces such as mtrinsics and CI commands escape to the 
PCJSIX name server when the file name begins with the . or / 
escape characters (see Fig. 7). 

The POSIX name server can also refer to all the objects in 
the director>\ For naming purposes, MPE accounts and MPE 
gifuips can be ti'eated as directories. Hence, the file 
PRGFJLEPX.DEVELOP c^m be refened to as/OEVELOP/PX/PRGFILE, 
Since the POSLX name sen^r does not upsliift names, the 
name /deveiop/px/prgtile cminot be used to refer to tliis file. 
Since file names are always in PfJSIX syntax in POSIX apph- 
cations, they don*t have to begin with or /. Tlius. if the CWB 
is /DEVELOP/PX/ledgef (see Fig, 4), the file name mam.c will not 
refer to the file MAIfV in group C of the logon accomit, but to 
the file named main,c in tfie CWD. The , is a vaUd POSIX 
chaiacter. 

A problem with the approach just described is that some 
interfaces might have to do special processing to accom- 
modate POSIX nie names. P'or example, the MPE :listfite 
commantl might have to query the MPE name server to 
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determine the type of file ivaiiie it Ls dealing with (POSIX or 
MPE) before* acrossing the file systeiiL However, this prob- 
lem is mininuzetj beraasc there is one c^'ntral file name 
server for parsing boih MPE and POSIX fib names. 

Rejected File Naming Alternatives 

The archil edure team consitlered and rejected the follow- 
ing ahentatives for file names using the MPE command 
tnteri>reter, 

PXUTIL. Tliis program wonld have been an MPE system utility 
used for suiijjoiting POSIX fiie aaines. For example, in PXUTJL 
a user could have purged a POSLX file its follows: 

pxutll> purge /ijsers/ietf/addr_bk, 

PXUTIL would have also supported the POSIX chdirO function, 
allowing the above file to be purged as follows: 

p}<Lrtil> chdir /users/jeff/ 
pxiitil> purge addr„b>( 

Among the few fumnioivs provided hy PXLfTlL would have 
been a niechiyiisn^ (usir\g : as the first eiuiratier) for escap- 
ing t(j the MPE coimnand interpreler so that the user could 
use MI*E ronunands from within PXUTIL This would have 
created prf>blerns when the CWD was chfferent from the 
logon group. Consider the following scenario: 



:hellQ jetf.develop,px 

ipxutll 

pxytil> chdir /users/jeff/ 

pXLJtil> iistfile @ 



(logon group px. develop) 
[run pxutil) 

[change working difectorv) 
[escape hack to MPE) 



Ideally, in this example the MPE :listtile command should 
display the files in the director>^ /users/jeff/. What happens 
instead is that the :listfile command transfers control back to 
the MPE command interface into the environment in which 
PX. DEVELOP is the logon grou]> and there is no eoneept of cur- 
rent working directory. Hence, :listfite would display the tiles 
in the group PX.DEVELOP. 

This example illustrates that using PXUTIL and the escape 
feature to the MPE contn^and interface would have re<iuired 
enhancements to the CI commajvds stHhey could have un- 
dersto* jd POSIX names imd the current working tiiretioiy. 
We concluded that if all tiie CI conmiands were eniianced in 
such a maimer tliere would have been no need for PXUTIL. 

Cl_PO SIX Toggle. Tliis alteniative defined a eonvmand inter- 
preler variable CLPOSJX, wliieh, when set. would enable 
some of the MPE command inteipreter commands to ac- 
cept POSIX-named objects directly. Tlie following sequenc;e 
illustrates this idea: 

:hetlo jeff.devBlop.px 

iprint dailY_log (tr>^ to use a POSIX file nanie directly 

^ in tlie MPE CI connnand PRINT) 

Invalid Character In FiJe Name, tCIERR 583) 

:setvar C LPOSIX true (tell the CI command to accept the 
POSEX file names) 

:print daily_log 

The nmin problem with tlus idea w as that with the \'aiiable 
CLPOSIX set to tiiie, conmiands tliat were not enhanced 
would not recognize POSIX named objects. Thus, in this 
scheme if the iHstfile conmiand w^as not enlimiced, the user 



would run into the same problem encountered with the 
PXUTIL utib ty. U'ha! is wTirse is that Lf the Jistfile conmiand 
were enhanced in tiie fvilnre to siipporl POSIX names, the 
user would hv sunK'ised to see different results. This means 
that the same connnands would have behavetl differently 
when Ihey were enhanced to recognize a variable like 
CLPOSIX. 

It would have been nice to have an '*accept POSIX names" 
switch on a per-command basis- In fact, the chosen design in 
w^hich tlie learhng characters . or / are used to escape lo tbe 
POSIX name svrvvr dtjcs pnHJsely tbab 

New Command Interpreter Commands. The last rejected idea 
was to create a new set of commands that would have 
directly accepted POSIX names. Consider the following 
scenarlti: 

:he!lo jeff.develop.px 
;chdir /users/jeff/ 

:pxlistf@ 

Presumably, pxlisti would be a new conmiand that behaved 
like listf and iistfile and undersTood POSIX names and the 
CWIX This command would hnve displayed all the objects in 
iJie CWD (/users/jeff/) as opposed to iistf and :listfile wliich w^oukl 
iiave displayed all the files ui the logon groujj PX.DEVELOP. Ttie 
biggest concern with ihis idea was that multiple commands 
would have been doing the same task. 

File Access and Security 

In the POSIX file access model a process can access a file in 
tite following ways: read, wTite, and execute/search. Search 
access applies to a du'ec^rory and execute access applies to 
an executalite file like a program file or a shell script file, 
Tliere is a stibtle difference betw^een read (as applied to a 
directory) and search access. If a process wants to open a 
dii'ectoiy and read the entries in it, die process needs read 
pemiission for that tiirector>'. But il' a process wants to ac- 
cess a file, say /users/jeff/addr_bk, the process needs search 
pennission for all the directories in the patii, namely, /, users, 
and Jeff in this particular case. 

The standard file access control mechanism of POSIX uses 
file pennission bits, and eveiy file in tlie POSLX directory 
structure hiis file pemiission bit.s associated with it. All 
directories in POSIX are Just files of directory t>pe. File per- 
mission bits contain the information alxjut a file tliat is used, 
along with other infonnalion, lo detentiine whether a pro- 
cess has lead, write, or execute/search permission for that 
file. Tlie bits are divided into three classes: owner, group, 
anc! other. In addition to the file permission bits there is a 
user idennfier (LID) and a group identifier (GID) associated 
\v]\U i^very file. File permission bits are set at file creation 
time and can be changed by the chmodO fimction. These bits 
can be read by using the stati) or f£tat(l fimcdons* 

For access control, processes are classified as belonghig to 
one of three access classes: file owner class, file group class, 
antl file other class. A process is in the file owner class of a 
file If tlie effective LID of the process matches the LID of 
tlie file. A process is in the file group chtss of a file if \}\e 
process is not in the file ow^ner class and if the effective GID 
or one of the supplementary^ (tIDs of the process matches 
Oie GID associated with the file. A specific implementation 
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of POSIX nia>' defiiie additional members of die file group 
class. Lastly, a process is in the file other class if the process 
is not in the file owner class or file group class. 

Implementations of POSIX may also provide additional or 
alternate file access control mechanisms. An additional ac- 
cess control nvechaiiLsm can only fmtlier restrict the access 
permissions deiined by tlie file permission bits. An alternate 
access control mechardsm, if enabled, is used instead of the 
standard niechanisni. Tlie altemaie access control mecha- 
nism has some constrainis, die chief being that it must be 
enabled only by expficit user action on a per-fiJe basis. 
Lastly, POSIX also allows privHege-based security in wliich 
access may be granted to a process if it has the appropriate 
pri\ilege. Each POSIX implementation can define what 
constitutes an appropriate pri\ilege. 

The MPE access control scfieme is based on se\Tral mecha- 
nisms such as a file access matrix, lockft^ords, and access 
control definitions (ACDs). Implementing P08LX 100^. 1 on 
MPE required a mechajiisni that conformed to the POSES 
1003.1 standiu-d. The exist In j^ MPK access control mecha- 
nisms did nol satisfy tiie reqiiireinenls si)ecified in the stan- 
dard, MPE file user types defined ftjr the file acc^ess matrix 
are not exclusive categories and MPE XL 3*0 ACDs cannot 
express access permissions for a files owner or group. 

To support the POSIX 1003. 1 access control mechanlsni, the 
architectiu-e team considered either extenduig an existing 
MPE mechanism or developing a new mcch^mism. It is gener- 
ally preferable to extend an existing MPE mechanism smce 
this approach often mijiimizes easterners' training costs and 
HP's development costs. Tliese benefits are maximized 
when the modification is a logical feature extension. 

The architecture te^nn nol it ed the close similarity between 
the evaluation of ACDs mul Ibe POSIX 1003.1 file permission 
bits. In both LmplenieatHit ionjs access coi^trol evaluation pro- 
gresses from the most .specific entry or classt to the most 
general enti>^ or class. A jiroce^s can nuitcb only a single 
<*ntry or class be<\iiise entries and classes are exclusive. Tlie 
two access control schemes are also siiiiilai' in the w^ay tJicy 
store access peiTiiLssions locally with I he file object. These 
observations led to the fiesign decision to unplement POSIX 
security using MPE ACDs, 

hi MPE/IX, POSIX J 003.1 file permission bits have not been 
imi>lemented iis a set>arate access control mechanism. 
Instead, POSLX 1 003. 1 functions support tlie file permission 
bits via the MPE ACI) niecbmiism. AC'Ds themselves have 
been enhanced to enable the ACD mechanism to operate as 
a POSIX 1003,1 additional access control mechaiiism and iu 
provide directory access crnitroL Fig. 8 illustrates these ac- 
cess control relationships. Tlic translaticm block perfontis 
the conversion horn file ijermissicm bits to ACD ff>rmat and 
vice versa. 

POSIX 1003,1 applications will continue to use POSIX file 
pemtission bits to specify access permissions mid will be 

t Eniry refeis tn an efilry m the ACD such as r, w, t®.^ in Fig. 9, and class is one ot the rhiee 
cJasses a pracess can be m fjle owdst class, liie qtmp class, or file other class 
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Fiu, 8, At:cL^HS conLrol irupleineiUat.ion in MPE/iX. Note that the 
All) meclianii^ni is ttie roundatLOri for bolii tlie i\dPE ACD intrinsics 
and tlip FOSIX fib ppmiission bits. 

nnawaie that file permission bits ai^e imt>lenierited on top of 
the ACD mechanism. On the other hand, MPE applications 
will never deal with POSIX file pennission bits; they will 
<\r'dl with ACDs, the file access matrix, mid lock^^ords. 
Wken a POHIX 100*J.l interiace snch as apen() creates a file, 
an AC'[) will be assigned to the file as part of the file creation 
operation. Wht^n the POSIX lOOai fimction ctimodd is in- 
Vf^kfHl f(> set ai ("CSS jiennissions for a file or direct ory, ACD 
infort^iaticin will bv manipulated. Simihnly, the statO aiid fsiatO 
fmiciinns will evaluate aji ACD and map the access pcniiis- 
sioris grant tv I l>y the ACD into file permission bits using this 
mapping in rever.se. F\g^ 9 illustrates the mapping between 
file pennission bits mitl MPE ACD entries. 
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Conclusion 

When the MPE XL oim-dtmg systeni wiis bring designed for 
the new F\^-RIS(' machines, back^'aiil c!ompatibi!ity with HP 
;}000 ntaf^liines nnuitiig tlu? MPE V operating system was a 
ni^ior goaJ, This resulled in the design and iniplementation 
of the conipatibility mode on tiie new HP :50€0 Series 9(W 
machines. Impiemenling POSIX on I he HP :U)00 Series 900 
machines present ed at leiLst as great a cliailenge to die ar- 
c^hitectiire team. Maintaining l>at^kw^ii<i cuntpatibiiity while 
seajnle,ssly integrating POSIX aiui MPE concepts wa.s one of 
tJxe chief objectives of the arcldtectitre teani. This paper has 
shown how tliis objective was aclneved in the U*chiiif a! 
areas of directorj^' structure, fde naming^ and fiJe access attd 
security. 
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A Process for Preventing Software 
Hazards 



Preventing software hazards in safety-critical medical instrumentation 
requires a process that identifies potential hazards early and tracks them 
throughout the entire development process. 

by Brian Connolly 



Since the occurrence of several patient injuries related to 
software failures of medicaJ ins! n J men tat ion J jnucli effoil 
has been put into fmding ways to ji re vent these softw are 
hazards in systems designed for medical use. Software haz- 
ards are a special category of software defects. If they occur 
during the operation of a system tl^ey may cause giave dan- 
ger to human life and prop^erty. Software by itself does not 
hann any one, bnl the inslRmumts it controls and the infor- 
n^ation i( collect-s from those ii^trumcnts can cause damage. 
Therefore, since accidents in complex computer-controlled 
systems involve hardware, software, imd himian fciHiues, 
softw^are procedures to avoid hazards must be considered as 
part of overall system safety. 

Many meiliods of analysis, prevention, and verification have 
been prop<;)sed to ban die software hazards. HP's Medical 
Systems (MSV) l.inii has researched imti experimented v^ith 
some of these nielhtxis and |.>rocesses. This paper describes 
how we combJrH^d the most ai)j)ropriate elements of these 
metliods to develop a soil war'e hazard avoiciance process 
for our r>rganization. We will also show how the process was 
appliefl to one proditci, 

MSY develops and manufactures instruments that provide 
clinical practitioners with patient information at bedside, a 



central nursing station, a ho.spital information system, a doc- 
tor's officet or anywhere the data is needed. Fig. I shows 1 he 
layout for a topical high-level medical intbnnation and moni- 
toring system. The iofonnation comes from transducem 
coimected to a patienL Physiologic electi'o mechanical activ- 
ity' is converted to analog electric signals. These signals are 
routed to data acquisition subsystems or motiules of a com- 
plete parient monitor The patient monitor electrically iso- 
lates tlie patient and digitizes tl\e signals, l^p to 12 modules 
can be coraiected to the patient. Tlie digital data is moved to 
the monitor softw^are subsystems where it is formatted, pri- 
oritized, and queued for display on the local patient monitor 
screen. In addition to local display, there is a proprietary 
local network, ealJed SDN (serial data network), which Is 
the pathway and prot(^col kn displaying selecteil data from 
up to 24 bedside monitors on central report ing stations. 

The patient data, whether at a bedside nionitor or a central 
station, is used by the clinician as one element in patient 
treatment- Therefore, in analyzing the haziirds in a medical 
instrument, consideration must be given to a direct hazard 
such as a software cmulition that ])roduces an nnsafe situa- 
tion for the patient, ajid the [possibility of patient mistreat- 
ment as a result of a monitor or centnil station indication 
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providing inaccurate trend data or failing to t^afi a patient 
alarm. Preventing these problem niK was t\\i' nuinvaling far- 
lor for the soil ware quality engine taring grouji at MSY to 
investigate software hazards and tJieii' avoidance in niptliral 
monitoring and reporting systems. 

The Hazard Avoidance Process 

Our hazard avoidance process is a combination of refine- 
ments to oia existing verification methodtjlogj!', which focuses 
on testing for hazards, and hazard avoidance analysis, which 
focuses on prevention, 

Verifieation 

Ulieii our investigation of software hazards began, the |}ri- 
mary focus of the group was testing and verification ut inte- 
gral e d em t)e dd ed i n i c lop ro cess or-based pati e nt n i o n i t o ri ng 
systems and central reporting stations, initially we exploited 
our experience in lestijtg for hazards to develop a verifica- 
litnr melbodology." This metiiodology w;is integrated into 
the normal product test development and test execution 
phases of producl development. 

The approach, as it is cunently used, involves documentation 
of the test strate^ and the creation of a software hazard 
avoidance fault tree, wliich shows the step-by-step verifica- 
tion of safety-critical subsystems. A portion of a software 
luizard avoidance fault tree is shown in Fig. 2. 

Generation of a software hazard avoidance faull Iree starts 
with identification of the most critical system hazards. 
There are many medio ds for identifying tJiese |)art iciilar 



hazards. The metliod we use involves investigating data on 
existing product-s atui discussions with internal and external 
experts. The data collected coixsists (jf HP customer com- 
plaints. report5i (virm the govemnient regulatory agencies, 
jouniaJ articles, and iruemal HPttefeci dam. External experts 
topically include eUiiicitins such as nurses, technicians, doc- 
tors, and biomedical engineers. Intenial expeits include MSY 
engineers and marketing product managers. The experts use 
the data and lugh-Ievel descriptions of the proposed i^roduct 
tf> detennine the highest-level tiazai'ds t« be avoided m tiie 
new" system implementation. 

The faull tree formal piovides a hierarchical decompositioi} 
of tht^ areas of concern. Al the lowest level of tJie tree, the 
"leaves" are tests that must be passed to estabhsh safety for 
die lowest subsystem level Por example, tests 1.1.1.2.1 
through 1.1.1.2.^^ in Fig. 2 must be p^issed to ensure that the 
patient monitor is able to detect a failure in updating patient 
data in a specilled time periotl, [Note that a failure in any 
one of these lower-level tests is analogous to a logical one to 
the next -higher level in tlie fault tree.) If miy test fails, it is a 
simple exercise to evaluate I he effect on the system. This is 
a valuable leal u re when considering releasing a system for 
clinical or beta testing and in making the trade-offs during 
deveiopnient about whether to remove orcoiTect an offend- 
ing subsy.si em. The software hcizard avoidance fault tree 
pro\ides a sunmmry of the plaii for verification of It^iy.ard 
avoidance of the system and a way to ensure that test cases 
exist for verifying that the systems software safety goals aie 
addressed. 
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At MSY, hazard avoidance tests are used to verify the safe 
opcralioTt of the system because wiieir the system is pat- 
tially tmplL^mented, it is userl iti a liiTtited basis iti clJDicaJ 
tnals. CMnical trials provide valuable feedback from our 
ciisloniers in the early phases of implementation when we 
cati easily make changes. 

Since the hazard avoidanc*e fault tree exists in a graphical 
representation it provides ticvplopers atid j^ovc^mmcnt regu- 
lators with a c:lear map ot die veritkaLitin strategy fur a 
product and its subsystems. 

Avoidance 

The software haztird avoidance fault tree and its associated 
tests provide a b^isis for imdcrstanding the compliance of a 
system with high-lcvc^I safety objc*ctives. As is the case for 
typical softwiire defecLs, verification activities during the 
tievciopiiicnt process focus on how to eitiier find defects 
earlier or ensure that they are not included in the first place. 

For finding defects, a whole industry provides tools for low- 
level, or white box testing. Instead of manual testing at a 
system level, commen ially available (ools can enable the 
developer to test individual software components in an auto- 
mated fashion. This is more rompreheusivc lium finrUng 
defects in the system test cycle, which occurs at the end of 
tbe development process. Tlie fociis is still on defect removal, 
rather than prevonlion. In the prevention case, tools such as 
fonnal flesign reviews are used on design and specification 
documents, and foiiiial insjiectioas are used on code. Tiiese 



prevention techniques are used fi-om the earliest user re^ 
qiiirements phase through the cock^ phase. Since* hazardous 
(iefects are a subset of eiII software defects, prevention tech- 
niques are needed to complement the verification process 
described above. 

For our hazard prevention program, we investigated pro- 
cc^sscs ttnd ^maJysis teclmiques that would fit into otir prod- 
lu't devt^opnif^nt ]>rocess. Tlie IEEE drtift dcKutnent thai 
dcfuies a sl^indard for software safety plans'^ recommends 
the following four docimients for safety-critical sofiware: 
' Preliminary hazard analysis report. This report should doc- 
ument the results of looking for potential hazards from the 
inititii system design documrntalion. 
So ft wiiTc safety requirement analysis report. This report 
should rlocimicnt: 

The list of hazards, Iheir c riticality level, and relevant 

associated software* reqitircmcnts 

Soflw^are safety design requirements and guidehnes 

Safety-related test requirements. 
Software safety design analysis report. Tliis reiaort may br 
divided into twf j parts. The first part addresses tht* safety 
analysis of the system s preliminaiy design, antl the second 
]r£iT\ addresses the safety analysis of the system's detailed 
design. 

Software safety code tmalysis report. This report should 
document: 

T]ie rationi:ilc for and types of mialyses tieribrmed on each 

module 
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Recdnftmendations for design arid cociiiig changes 

Detailed test recommendations 

An evaluation of safety requirements, 

Tfie draft atso list^ii several techniques for hazard analysis 
and avoidance. Some of these techniques m elude: 
Formal inspections, A formal method of peer review of 
target dociunentation (design documents, code, test filans, 
el***) til at culminates in a review meeting. Each member of 
th*^ review team has a specific role in tlie re\iew^ meeting. 
The objective of the mspection or review process meeting is 
to identify issues and defects, wliich are documented and 
aridresserl later hy ihe reviewed documents author/* 
Fault tree analysis. A logic diagram of expected event 
sequences. It can be used to show how hardware, software, 
mechanical, and hmnan interactions can cause a hazard 
(see Fig. 3). 

Petri nets. A diagramming technique^ that enables timing 
information to he incorporated into I he safety analysis.^ 
This technique helps to identiiy software events that are 
either too early or too late, thereby leading to hazard (Condi- 
tions. While fault tree analysis accents the effect of unex- 
pected events m a logical linkage, the Petri net focuses con- 
trem on correct events occurring at possibly incorrect tunes. 
F^ailure modes and effects iuialysis. This involves an exami- 
nation of all the failure modes in a system widia description 
of the caiLse and ell eci associated with the failure mode. 
Failure modes and effects analysis results can be docu- 
mented in a table (see Fig, 4), 
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Detailed C^esign 
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Software Hazard 
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• Event tree aimlysis. Tliis analysis moves events logically 
through Ihe system to determine the consequences of these 
events. An event tree analysis is different from a fault tree 
analysis in that a fault tree tnices an unde sired event to its 
causes. Fig, 5 show-s an event tree analysis using a stale 
machine approach. 

• Formal specifications. A rigorous mathematical method of 
defining a system, with rules and definitions that provide 
the basis of proof ,*^" 

Other teclmiques proposed in the IEEE standai'd include 
perfonnance analysis, sneak circuit analysis, criticality 
analysis, and fault tolerant testmg. 

The form we chose for our hazard avoidance fjlan includes 
mod ill ed versioJis of the documents deiined in the IEEE 
standard, some of the analysis teclmiques described above, 
and the hazarrl verification process dest^ribed in the pte- 
vioiLS section. Like the IEEE standard, our plan allow^s the 
analysis fonnat to be adjusted to fit the problem. The acijust- 
ments are made according to the experience of the the soft- 
ware quahty engineer and the type of application beuig con- 
sidered. For instimce, most of our analysis is in the form of 
formal inspections, but an engineer may decide Ihal instead 
of using a state machine to model some function. t*elri net 
analysis is more applicable. Also like tfie IEEE standard, 
t be emphasis is on aj^aiysis and documentation during the 
software development phases. 
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Fig. 6. Software iiaiiard avoid- 
ance process flow in rije sofiware 
life cycle. 



50 



Jiwf' I9f>3 l^ewlett-Packiird Journal 



)Copr. 1949-1998 Hewlett-Packard Co. 



Inpuls 



Software Arcltt^&^tiire SEid Otbci 
Evoluauarr Dacuments 



Ha^aril AvoEEfance Process Slap 
Preliniiitaiv Hazard An 3 tf sis 



Deliverables 



IM frf Pirtsntially Hazandoujt Ar««s 



Preliminary Kazaril List High-Level 
Software 0&si§n 



Software Fteqvrremtnts Hfijart 
Analysis 



fEecommendBtions for Design Changes 
in Areas Oefmetf by PrBliminary Ha^arrt 
Analysis 



Preliininafv Hazard Ust. Lnw-Levs] 
SiQflynr« Das(|n 



Detiiled OestBD Hazant Analrsis 



Recommenilatians for Detailed Dani^n 
Changes m Arees Definetf by PreHminBry 
Hazaitf Analysis 



Prelj miliary Hazard List and Coife Software Hazard litspectteit List 



List fff Coite Functions Requiring F&nitil 
Inspection in Ha2ardous Areas 



EKteraal Specjficatiiiiis 



Software Hazant Avoidance Fsull 
Traa 



Validation Tests lor a "Safe" Sy^etn 
Documanted in Fauh-Trae FofoiBl 



Fig, 7* Inputs and deliverables 
associated ^1tji each of the 
steps in the hazard avoidance 
pnocess. 



The hazard avoidancp act iaI ties that take place during the 
softTft^are development phases are shown in Fig. 6. The in- 
puts and deliverables to the hazard avoidance activities are 
summarized in Fig. 7. Note that although the names of the 
documents may differ slightly from the lEEK-recommended 
documents, the r on tents remain the same. "^The one excep- 
tion is the software hajtard inspection list which corre- 
sponds to the IEEE-specified software safety code report. 
We provide the same contents as the IEEE report in terms of 
results, but we are more specific in mentif>ning the type of 
analysis used for hazard avoidance. Tlie result is that no 
matter wiuch fonn of analysis is chosen in atiy development 
phase, the process documentation contains tlie choice along 
with the results for each phase. The overall benefit is the 
capability to follow the hazard and its treatment tluough 
each development phase* 

.Analysis and Verification Together 

As showTt in Fig. ti, hazard analysis begins in the reqime- 
nients phase of a project. Wlien a project establishes user 
requirements and has identified a high-level ai<iiitecture for 
a product to fulfill the requirements, work begins on tlie 
prel i rn i } m ry k a zu t d mta lysis. 

With the early documents completed^ data from similar 
previously released products such Jis enhancemerU requests, 
defef^t-s, and government, regulators' reported couiplainls aie 
combined together for analysis. An evEiluation teatti consist- 
ing of users, quality engineen^, developers, mtenial regulatory 
persomiel, mid marketing enguieers reviews the collected 
data anfi tjroposed protlui t architecture, iind with eacit 
member's exi>erience base, decides on the levels of concent 
for baziirds identified in the new product. 

The hazards are rated minor, moderate, or msyor based on 
the consensus of the group. Each hazard is evaluated to de- 
temiine its impact on patient care if the liitzard were not 
removed. These hazartk)us Eu-eas provide the focus for the 
quality engineers fiUure imalysis during development and 
verillcanon. To contplete the prelunjnary hazaixi anaiysis^ 
eacli hiizarrl has associated clauses :ind methods of verifica' 
tion listed. Each cause indicates how a problem might, occiu- 
in the given architecture, and the verification list describes 
the methods for making sure the hazard isn't included in tiie 
product. Fig. 8 shows a ptMioii of a preliiiunao^ lia^^arrl report 
containing the information mentioned above. 

During the specifuaiion [ihiise of product development, the 
software fvquiremtmLs hazard analyfiis, w!iich shows re- 
sults of attatyzing tlie software requirements, is produced. 
The requirements are provided in many forms such as datti 



flow diagrams, verbal descriptions, entity relationship dia- 
gi'ams, and fomial specifications depending on the form of 
software being developed. The areas identified as hazards in 
the requirements are analyzed according to whatever 
method was defmed in the preUniinai^ hazard analysis. 

In addition to performing a hazard analysis of the require- 
ments during the specification phase, a software hazard 
aimdaiice fault tree is aJso generated from the data provided 
in the pre hnii nary hazard analysis phase. 

In the implementation phase, a detailed desigri hazard 
anaii/sis is perfonned to examine the same areas studied in 
the pre\ious phase, except this time the details of the design 
and implementation are exanvined. Following tlie detailed 
design hazard analysis, the software hazaM inspection list 
is created. This Ust is a collection of the softw^are functions 
requiring inspection in the hazardous areas of the desigrt 
We require inspections of all software functions that have a 
cyclomatic complexity of 10 or greater 

Tlie portion of a hazard analysis matrix shov\7> in Fig. 9 pro- 
vides an ovei-view of the luizard avoidance histor>' for two 
hazartis identified in the prcliuiin^u^' analysis phase. 

Once all Uie analyses and tests have been completed, the 
documentation is kept in the project notebcjok and tlie soft- 
ware test archives for the product. The notebook and ar- 
chives are kept as evidence of proct.^ss adlierence required 
by i nd 11 St r>^ and government regulator>' agencies. 



Softwarfi/Hardware Hazard 3: Error departing Failure 

Causels^: Design Imfilementarion Failure 

Verif i cati on: Inspect! on with pa rti cip a ti o n of S QE to verf ty soft wa re 

design for hazard avoiilance. Use software hazard avoidance fault Irae lesis 
to verify design and irnplententation of error handling and reporting to 
correctly idefitify errors and 111 sir soorceE. 

tevel ol Coneern; Minor Severe orrors cause faitsafe inoparabiliry «f the 
system, posing inconvenienca (o staff users. 

Software/Hardware Hazard 4: SDN Backoff Failure 

Cause(s^: DBSign/lmplemontation Failure 

VarificatioR: tnsp action wtth participation cf SUE to verify software 

design for lia;ard avoidance. Use software hazard avoidance fault tree tests 
10 verify design and implamontalion to avoid conflicts and incorrect bahav- 
inr in backoff determination. 

tevel of Qoncern! Moderate. A confusion could occur between central 
stations as 1q "ownership" at bedside information Tfiis could result in 
misdirection of patient information, alarms, and recordings tf the hachuff 
atgaritbm is incorrectly implemenied- 

*SQE ^ Software Quality £ngineerio| 
F'ii;. 8» A portion of a f:.ri'Ju[iMi,sr> hazard analysis report. 
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Fig. 9. Hitzard avoidiuicc liLsl or> for Uvu software hii^'^irds as rht^y am mmlyz^id m\t\ vt^rififHl limitiij iiw hazaid avoidance prc>cess. 



Results 

The software hazard avoidance fault tree porlion of the haz- 
ard avoidance process has ht^en Ltsetl in eiglit MSV jJifidiKis 
aiid product enhancements since 1989, No safety tlefecls 
reQUiring inslninienl reccUJs have been reptJrteti for these 
products, hi one product line, haxiird avfjidaiice testing dis- 
covered 32% (as compared to 15% in previous |)roj ects that 
used traditional development and testing processes) of all 
serious and i^ritical defects that would have had an effect on 
patient welfare. 

As of writing of this articie, one product has used and com- 
pleted tlie fiih hazard avoidance process described in this 
paper. Several other projects are in different stages of using 
the process. In liie project that lias completed (he process, 
two forms of analysis were used during ttie preliminary luiz- 
aril avoidnnce [>hase: fonnal inspections and fonnal methods, 
The I j III k of the hazards were found using fonnal inspec- 
tions. A total of 23 inspections were perfonned on product 
documents, finding IMi of all hazardous defects. 

Using HP-SL"^ (HP Specification Language) two areas of po- 
tential hazards were speclRed and examined. Four possible 
hazardous defects were identified with formal methods. 

Conclusion 

Ttie MSY development mid implementation of the haztird 
avoldatice process has helped provide products with fewer 
recalls, providing a higher level of customer satisfaction. 
The results achieved so fm^ with tlus process have been ex- 
cel ten t^ Tlie emphiisis on defect prevent i^m will continue to 
pen''ade our development effort, with the hijzard avoidance 
process as the conierstone. 

Defect prevention and analysis are not enougli, and this pro- 
cess provides a verification trace back to the requtrentcnts 
phase of development. Also tliis process provides a system 



view of Uie objet!tives set in tlie ejirly phases of a projetl to 
ensitre their correct implementation , 

From our experience so far, the cost of using this process 
depends on t he form of analysis chostni. The ftiirm of analy- 
sis has to be carefully f*onsi<lered when a i>otential Itazard is 
discovered. The \^es of analysis and Uie api)litability to ttie 
problem must be iuvestigated. The cost/t>enefit analysis may 
have to consider such questions as the cost of a i>otential 
recall, the possible reuse of functional elements in another 
pro due tp and always, the effect on the patient and user 

No matter what fonri of ana lysis is eiiosen. the process steps 
have been standardized and documented and are availalile 
for government regulators, other developers, and any other 
interest efl parties to e>:anupe. This process provides the 
evidence that we have done all we can do to prevent soft- 
ware hazards before building the instrument. 
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Configuration Management for 
Software Tests 



To support software test reuse and to make it easier to ensure that the 
correct software versions are used to test printer products, a software 
test management system has been put in place. 

by Leonard T. Schriiatli 



Many software development organizations have begun to 
fonnalJjEe software reuse as a way to improve productivity 
and I ri crease quality. Howev^er, most of the effort is put into 
reusai>le components tlial aiT used for creating software 
pioducis. Methodologies and processes can exist for the test 
<levelopnient effort as well If software components can be 
reused effectively; test comt>onents can be reused also. For 
any reuse program to be successful, a formal process and 
sop|>or1 tools are essential. 

The software quality department that serves HP's Boise 
Printer Division and Netw^ork Printer Division maintains a 
vast printer test librai^, whicii includes perfonniuice tests, 
confomiimce tests, other black-box tests, test procedures, 
t^st results, test documentation, and known-good output for 
comparison. The test library requires extensive scripLs to 
ext rat 1 and execute tests for various projects. Majiy new 
tests are ieveraged from old tests, but there is only a primitive 
browsing mechanism la aid in locating them. 



Fig. 1 shows the steps a^ui daiabases involved in submitting, 
reviening, and executing tests in our existing test process- 
Except for test execution, the processes shown m Fig. 1 are 
scrii Jts iha! aie primarily responsible for mo\1jig test data* 
from one database to another. Kacli tJatabase represents a 
different state in the test development process. 

The process begins with rest data being moved from ti\e iab 
to the submit database. Next tiie test data is reviewed to see if 
it is complete. For example, tlie test program is checked to 
make sure it compiles. If anytlting is v^Tong with The test 
data, il is sent back to the lab for conection, and if every- 
Uting is okay die test data is moved to the trial run database. 
During the trial run phase, the test program is executed to 
flush out any problems. If tliere are j:>roblemSt the test pro- 
gram is sent back to the lab for repair. If ail goes weU, the 
test program is moved to the testlib database. Once a test is 

■ BesJdes itie tesi pcogram, lest data may also include items such as lesi {locumeirttation and 
incJu'de files. 
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system. 
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in the lestlib database, it. is rt^aiiy for rormal test execution. 
Test execution involves not only testing the product, but also 
capturing data for various dataliases and generating a test 
report. At any poim in I his process rno<iifi cations can be 
made to the test data, resulting iu moving data Ivom the 
database (state J it is in back to the submit database. 

To improve this process widi tools that manage test selec- 
tion anti assist in test development for the varioiLs software 
and fmnware projects at our divisions, a test library man- 
agenieni system, or TLMS. has been developed. This new 
system is gradually Imng jihasefl in lo enhance and replat^e 
parts of our existing test system. Tlie rest of this paper de- 
scribes tJie developnientj featm-es, and test life cycle of the 
test library management system. 

Goals 

Seveial goals were established early iji the TLMS develop- 
ment process. First, there was no doubt that a need existed 
to track ail tests under a version contiol system so that pre- 
vious versions of tests could be recovered and executed if 
the fmnware or software was revised to fix defects or add 
enliance meats. It was aiso desirable to be able to track test 
vej"sjons with finnware or stjftware vei-sions so that custom- 
ised tesi suites txnild be created to test spec^ifir feattires oi' a 
particular vei'sion of firmware or software. TLMS also needed 
to ensure cleai^ ownership for each version of a test so thai 
there was only one individual who was responsible for any 
antl all changes matie to a particular version. The entiie 
maintenance process needed to be more fonn^Uly defmed 
and automated as much as possible. Anotlier iinportajit goal 
w^as to facilitate test reuse througli a test case cltissification 
scheme and a test location mechanism. This scheme would 
aid in test case selection and test suite development. 

Configiiration Management Tool 

TLMB is based tm an objechoilented contiguralion manage* 
ment tool called Case War e/fM, ' wluch pro\ides a structured 
development eniironment witli a turnkey model that can be 
used for most softwaie developn\ent projects. This configu- 
ration management tool also provides liotli a graphical OSF/ 
Motif-based user interface and a command-liue user interface, 
and it rims on HP 9000 Series 300 and 700 worksl:ations, 

CaseWare/CM's built-in flexibility allowed us to create a cus- 
tomized model to fit our test development life cycle. As user 
needs change, the model can be modified without impacting 
the objects stored in the database. 

To help with our reuse efforts, CaseWtire/CM reconls the 
development history of the lest librai^ its tests me created, 
nKjdified. or imported. Tlte test libraty configuration Ls sMui- 
dardized across project^s so that test developers or test con- 
sultants who are I how sing or searclii ng for reusable tests 
can easily find them. Tests and test suites are treated as 
objects that can easily be included m odier test suites. 

Features of TLMS 

Components and Attributes 

Most of the oi>e rat ions of TLMS center around comxionents, 
A component is a related set of attributes that describe an 
object such as a test program. Each component has a num- 
ber of attributes including its name, t.3^e, status, source, 



description* author, subsystem, creation date, and date of 
last modification, A component also has a version attribute. 
Specific versions or instances of objects are referred to as 
vo mpo n en I versions. 

Different types of components exist for different types of 
objects. Object.s in our case are test prograniSj include files, 
spreadsheets, documents, shell scripts, C source files, and 
font files. Some component types are built into the configu- 
ration tool and otliers can be created and added to the model 
as needed. Specific behavior is given to each component 
type, such as how tlie source attribute is compiled or edited. 
Table I lists some of the built-in types and sorue of the types 
tiiat have been created specifically for TLMS^ 





Table 1 




Component Types 


Built-in Types 


Description 


csre 


C source 


inci 


C include 


Isrc 


lex source 


ysrc 


yacc source 


Shsrc 


Shell source 


C4 + 


C++ source 


ascN 


ASCII text 


swasm 


Software assembly 


TLMS Customized Types 


pmac 


Printer macro language source 




(main test program) 


p_inc] 


pmac include file 


post 


PostScript® source 


msword 


Microsoft - Word docimient 


lotus 


Lotiis ~ 1-2-3 ■' spreadsheet 


excel 


Microsoft Excel spreadsheet 


font 


Soft font file 


testasm 


Individual test assembly 


suite 


Test suite assembly 



The naming convention used to designate a component 
version has four parts, which helps to avoid ambiguity. Each 
part is separated by a slash (/). This slash serves only to de- 
lineate the four' parts of the component version nanie m\i^ 
has ntJthing to do with a file system luerarchy. Tlie fom parts 
are: subsystem, type, name, and version. Thus, for a test with 
a subsystem of fonts, a type of pmac, a test name of fortpri4, and 
a version of 2 the four-pait name is tonts/pmac/fDntpri4/2. Each 
of the four parts, along with the state of the component 
version, is represented graphically in Fig. 2. 

A special type of romponerU \'ersion called an assembly is 
used to group oUier component versions togelhen In the 
context of TLMS, a test assembly consists of aJl component 
\'eisions needed to nm a test. A mininimn test assembly must 
include a test program, a test procedure, and some expected 
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Subsystefn/Type/Hame;/Ver5ig]i 






Fig, 2. A grapliica] representaiioii of a component \'ersion. 

results. An assembly is somewhat analogous to a directory 
in a file system. The graphical representation of an assembly 
cSsplays an extra box around the name to distinguish it easily 
from regular coiuponent versions (see Fig. 3). 

An assembly also has its own collection of attributes- includ- 
ing name, status, version, owiier^ and subsystem. An assem- 
bly may also have its owTt customixed atlributes. An exiuiv 
pie would be an instaUarion directory attribute, which would 
serve as a defmition of where to install source files in the 
file system once they have been extracted from TUVIS. 

TLMS uses two special assembly component versions which 
are customized for the rest library appbc:ation. The fust is of 
type testa sm (test assembly ). which is tlie b^isic builduig block 
of test suites (see Fig. 3). There is no limit to the nimiber of 
component versions that can be inclutied in a test assembly 
However, by TLMS conveiition ihere shoiild be only one main 
test prognmi per testasm, ami as juany include files as needed 
for the test. Each test assembly shouhi also have some lest 
design documentation describing what is bel!ig tested. 

The other special assembly component version is of type 
suite. Tills assembly is used for grouping test assemblies into 
test suites. A test suite can consist of one or more testssms 
and one or more test suites. Although there is no require- 
ment that a test suite consist of only suites iUid testasms, most 
other coniponent version types should be part of a l&siasm 
and not a suite. 



Component versions can easily l}e placed into an assembly 
by creating a iist of components to lie bound into the assem- 
bly. The operation reconfigure is performed, which automati- 
cally selects the specified component versions and binds 
ihem into the assembly. The hst of components only neetis 
lo have the first three pans of the four-pan nanie for each 
component, which causes the latest \ersion of the compo- 
nent ro be botmd into the assembly If a specific version of a 
component is desired, il may also be specified as the fourth 
part of the name in ihe list of components. 

The reuse program being dev^eloped for tests in TLMS will 
make use of customized attributes found on each testa sm. 
These attributes make up a faceted classification sciieme.- tn 
which the attributes form a tuple tliat describes a test. Quer- 
ies to TLMS use the classifications to extract a set of tests 
requested by the tester F'or example, a quer>' n light be to find 
all released tests for a specific printer that will exercise the 
font selection capability of the printer 

Test Suite Hierarchy 

Components representhig tests and test suites are grouped 
in a luerarchical fonn to farilitate test location. A catalog is 
maintained of reusable testasms (test assemblies) and suJteSt 
any of which can be easily bomid into any rest suite for any 
project. In this manner project-specific test suites can 
quickly be developed by combinuig new and exisrir^g tests. 

The test library has at its highest level an assembly of type 
suite named testlib (see Fig. 4). This assembly consists of 
other assemblies of type suite. One is named catalog, which 
contains all of the tests that are used in more than one proj- 
ect. This is the basis of the reusable libraiy. The catalog is 
hierarchically arrangeci into logical suijassenihlies, wfiich 
makes it easy to find tests. Printer conformance tests and 
other black-box tests that can be use<l by more than or\e 
project are found in the catalog. 
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(see Fig. 3J 

Other test suite tisstnnbiies bound to the testlib are specific to 
projects and arc named for the project (e.g., project_a or 
project_b). Each project assembly consists of a test suite 
nameti proLsuite, which contains all of the suites and testa sms 
ttmi make iip the entire test suite for that project. A proi_sijite 
may contain links to testasms or suites that ai'e in the catalog, 
or may liave its own special comiionent versions tailoreti for 
the specific project, A project assembly may also contain 
one or more testasms or suites witb a narne that corresponds 
to a version of sofi Wiire or Ilrntware that is being tested. For 
example, a suite nuiy be developed to test certain fealiu'es of 
version L2 of some finnware, and hence could be named \/l,2. 

The subsystem name for all assembhes for a specific pro^ject 
should match the name of the project, unless the entire suite 
or testa sm is being used as it came from the catalog. This al- 
lows extraction or reporting on all component versions that 
are specific to the project. For exaniplet in Hg. 3 the compo- 
nent versions with tlie subsystem nanie fonts are actually 
from tlie catalog, 

RoLes 

Much of the activity in TLMS is allowed or chsallowed based 
on the role of the person interacting with TLMS. Users are 
assigned one cn^ more roles. Each role allows browsing 
through (he test library, along with certain other privileges 
brieHy <lescribed below. 

Author An author Ls allowed to create a new cotiiponent ver- 
sion, derive (check out) a new component version from an 
existing component version, and ii^tall tests on the file sys- 
tem for executioTL An anthor who has created or derived a 
component \'ersion becomes the owner of the component 
version uniil it is reviewed, approvetl, mid released. 

Test Librarian. The test librarian is responsible for the content 
and stnictiire of the overall test library. The test librarian is 
the only one able to create or manipulate component ver- 
sions of tyi.ie suite. The test hbrarian also makes sure that 
each test is executed to verify thai it w^orks correctly before 
putting it into the test library; Finally, the test librarian is I he 



Fig. 4. A [Jortion ot& TLMS tesr 
siiitp liierarchy. 

only person who can officially release component versions 
into the test library. 

Test Consultant. The test consult ^int is responsible for re\ae%v- 
ing test con^ponent versions before submitting them to the 
test lil^rarian for a 1 ricil test nirL Test consullants are only 
able to modify componeut versions that l)ek)ng to projects 
to which they have l>een assigned Test consultinUs, in coop- 
eration witli R&IX define ilie component versioits that belong 
in a test suite, hut they are not allowed to create them. 

Test Technician. The only activity that a test technician is 
able to perfonn in TLMS is a test-suite build, which, in the 
context of TLMS, extracts all test sources, procedures, mas- 
lei's, m\d anything else that is required to execute a lest and 
places ihen^ in (he file systenL Tests can then be executed. 

TLMS Admitiistrator. The TLMS administrator is the superuser 
of the system and is responsible for adding new^ users, 
chimging their roles, and making changes to the TLMS 
model installefl in the test hbnuy <latab;ise, Tlie TLMS ad- 
ministrator is also 'Ab\v to modify any cornp^menl version 
and generally circumvent the built-in security provitled by 
the rules set up in 1 he TLMS model This role must be used 
with caution. 

Software Development Engineer This role is similar to the test 
technician role. Ai\ individual niih this role has pennission 
to browse Ihrough the lest library and is able to perfoiTn a 
test-suite build to extract tests and place them in the file 
system for execution. 

Guest. A gues! only has permission to browse through TLMS. 
A user with this role carmot modif>^ any compr>nent version^ 
extract tests via a build operation, or perform any other 
operation. This role is pro\ided for users to look at tests 
currently in the test library. 

TLMS Life Cycle 

The main life cycle for tests Is governed by a series of states 
and transitions that affect any assembly of tyi^e testasm (test 
assenthly) imd the comiKmem versions that are bound to it. 
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A comptjnent \eraion progresses through spveraJ states 
from tl\e tm\e it is rheckeci out or created until it is released 
into the test librar>'. Most transitions are made directly to 
component versions attache* J !o a test assembly, and all 
component versions bound to the testasm make the transition 
automaticaDy. Transitions can also be made directly to an 
individual c^oniponeiil version. Fig. 5 shows the slates and 
transitions for the TLMS main life cycle. 

The initial state is called private. Most newly created test 
assemblies begin the life cycle with this state as their default 
status. A component \^ersion in this stale can only be modi- 
fied by Ihe author (owner) who created it. A private compo- 
t^ent version can only he bound into testasms created by the 
same owner A new version cannot he derived from a com- 
ponent version in tiiis state because it is considered to be 
unstable. 

The only transition allowed from the private state in when the 
testasm is ready to be published. PiiblLshing a test assembly 
moves it from the private Slat e to the vworking state. The tests 
are made public for the first time w^hich jneans that some- 
one else can bind these component versions iiito another 
testasm, and the librarian can bind a testasm into a suite- This 
transition is initiated by the owner of the test assembly. 

The worlcing state assumes that the tesLs bound into a testasm 
are in working condition. In other words, ihe test can be 
executed. It may not be completely correct, but at least it 
runs. The owner is still the only one wl)o can modiiy a com- 
ponent version. New versions can be derived from any cojii- 
ponent vei-si^jn in the working .state (or any subsetinent state), 
but when this happet^s, the soiu^ce attribute of the originid 
component version is frozen. The test assembly containing a 
modified component version can continue to proceed along 
the life cyclc\ but all sourte modifications miust be made to 
S he new component; version to avoid a double maintenance 
problem. 

The only transition allowed from tite working slate is when 
the test assembly is ready to be reviewed by the test consul- 
tant. This transition moves the test assembly from the working 
state to the finalreview state. This transition is also initiated by 
the owner of the test assembly. Klecfronic mail is sent to 
notify the authorized test cons n I tan t thai a testasm has been 
subntitted for flruil review. 

The fina [review state allows the test consultant to review the 
test for completeness. All tests should be complete and 
must contain all of the necessary documentatjor^. Once a 
test assembly is in the fina Ire view state, it can no longer be 
modilled l>y the owner. Only the proper test consultant has 
modification privileges* 



Two trattsitions are allowed from llie fin a! review state. The first 
is the transition thai moves the test assembly back to the 
working state for rew ork by the owTier A report of the prob- 
lems encountered is sent to the owner by elecironic maiL 
This report is required before the transition is made. In the 
graphical user interface, a window opens that allows the test 
consultant to enter the report, and in the command-line inter- 
face, the test consultant can attach an ASCII file containing 
the report. 

The second transition allowed from the final review state 
moves component ^Trsions to the triafrun state. As test as- 
sembhes make this triinsition. electronic mail is sent to the 
test librarian indicating that a test is ready for a trial run. 
EJectronic mail Is also sent to the author acknowledging 
that the test has passed final review* and is ready for a trial 
nm. Botii transitions from the finafrevtew state are initiated by 
the test consultant. 

The trialrun state allows the test librarian to review a test for 
completeness and ensure that it executes properly. Tlie test 
librarian also makes sure that the testasm has a unique instal- 
lation directory so that the test cai^ be installed onto the file 
system without overv^ riting other tests. The rest librarian is 
the only individual who cim modify any component version 
in the trialrun Slate. Tliis is to prevent ^my changes to liie com- 
ponent version without the test librarian knowing about 
them. 

Two transitions are allowed from the triatrun state. The first 
transition moves component versions from the trial run state 
back to the fina I review state if the rest assembly is rejected. 
This transition is used for those tests that do not nteel appli- 
cable standards or do not pass tlie trial run. A report of wtiy 
the test was rejected is sen I via (electronic mail to b{>ih tite 
test consultant and (he <iwnt i (similar to the repoH seni 
when the test assembly is sent back to the working state for 
rework). 

The second transition allowed from t!ie trialrun stale moves 
the test assembly to the released stale. Tliis transition is 
made only after a testasm has successfully ccimpieted a trial 
run and it meets idl of the applicable standards. An acknovvl- 
edi^tnent is sent \ia electronic maii to the author, the test 
consuitimt, ;md others who are interested in knowini^ when 
a test is reieiised. Both transitions from the trialrun stale are 
initiaied by the test librariai\. 

The final state is the reJ eased state. Any component version 
in this state must have been approved by the test librarian 
and by definition, be part of the official test Ubrary. A testasm 
cannot be released unless all of its member component ver- 
sions are released. Component versions in this state are no 
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Fig. 6. Tlie TLlitlS test suite life cycle. 

longer modifiable by anyone. They are static, mrludiiig all 
attributes. The only exception to this is a coninient attribute, 
which can be updated at any time by the librarian if more 
info miat ion needs to be stored with a test. 

A separate, shorter life cycle for componenl versions of type 
suEte consists of two states: unreteased and released (see F^g. 6). 
This Ufe cycie exists to faciliLale the creation of large test 
suites wilhoitt the overhead of having to move componenl 
versions of type suite through all five states of the main life 
cycle. Kemeniber that componenl versions of iype suite are 
tyi>ically made up of many test assemblies, anti each test 
assembly is typically made up of a test program and many 
ottier fdes. 

The initial state is called urreteBsed. Component versions of 
type surte in the unrefeased state can be modified as often as 
neressary^ t>ut only t)y tlie test librarian. TYansitJun from die 
unreleased state to the released state is allowed only when the 
test suite is determined to i>e frozeix (no n^ore rtiatiges). 
Tins transition can only be initiated by tlie test librarian. In 
the case of suites, all component versions bound to it must 
eitlier be released already or released at the same time. This 



means that all rtu!*lrpn (test assemljlies or suites! not alr^eady 
released nuist I )e in the trial run state or the unreleased state 
(the only two states l.liat allow transitions into the released 
state), or the transition will faiL The released state of this 
short life cycle is the stmte as the released state in the main 
life cycle. 

Comparison 

The TLMS main life rycle is intended to intprove the test 

process described e;ulier and shown in Fig, 1. Overiaving 

the TLMS life rycle states shov^ii in Fig. 5 witli the processes 

slKJwn in Fi^. 1 results in the process diagram shown in 

Fig, 7. Tins diagram shows the following benefits to the 

test process with TLMS: 

Tests are maintained in one database, and there is no need 

to move files from one database to another io change state. 

Attribute information such as status, test owner, mul creation 

date is easily stored and queried. 

Test development history is automatically recorded. 

The test maintenance process is easier to control. 

The test process is simpler. 

Security and Access 

Security niles Um each model can be written tmd enforced 
to mairuain the integrity of the database. These ndes and 
privileges allow^ nr disallow component version creation^ 
modifjcation, transition, mid deletion based on the state of 
the component version or the role of the user. Security Riles 
in TLMS enforce the privileges ai^d operations described in 
the life cycle section. 
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Fig, 8, A t>ortion of a TLMS test 
assembly report. 



User Interfaces 

Two user interfaces e5dst for lliMS. One is a graphical OSF/ 
Motif-based interface that nuis on the X Window System. 
Users can select actions from popup menus and na\igate 
tlu-ough the various windo%%'S using a mouse. The otlier in- 
terface is a command-line interface, j\lthough a graphical 
interface is helpful in giving the user a \'isiial picture of the 
elements m the test library, a coiiunand-line interface is also 
available to perform matiy sLrnple commands. Among these 
are commantis to create a (component version, move an as- 
sembly of component versions from one state to another, 
modify the source attribute of a component version, install 
the tesl suite onto the file system for execution, tmd import 
an extemMIy developed test into TLMS. 

Reports 

Reports of useful inlbmiation are obtained firom TLMS 
through some com maJKl -line queries. Some examples of 
reports that are easily oblainabie die a list of all component 
versions in a test suite, the status of all component versions 
in an assembly, die authors of a list of component versions, 
a list of all projects using a given coniponent version, and a 
list of all component versions currently in a given state. 
Fig- B shows part of a report of all testssms. 

Benefits 

TLMS provides an easy, consistent method of maintaining 
and accessing all tests. Those who need to interact with the 
test library can find what they want wiUioitt having to Jisk an 
expert. Also, the entire process of test development and 
maintenaru'e can be structured and cfintrollett Tlte tlevelop- 
metil hisliiry of tests in the test lihraiy is capmred autiunali- 
cally^ Testes can be identified and selected for a given test 
run^ and a customized test suite can tjuickly be created. 
Tests tliai are not yet ceitified and released by the test 
libnuian can still be executed if needed. 

T\\e sofh^'are test center is able to increase testuig effu iency 
by executing a test suile customized ft)r a test iiui instead of 



tlie myriad of redundant tests that are present in the old test 
library. Jt is also much easier to veriiy- that tJie proper \ er- 
sions of tests are executed for any version of firmware or 
software. 

As with all programs, new enhancements and changes will 
probably be requested from the user commimity. TLMS fea- 
litres can be n^odified and extended without impact on the 
ol)jects stored m the database. Finally, a more formal test 
reuse program can be established^ w bich will aHow test de- 
velopers to take adv antage of the work of others. This wHl in 
turn decrease the total test development time, a significant 
portion of a project's schedule. 

Conclusian 

The testing process is an important part of the software life 
cycle. Without the proper tools and stnicture, it can become 
inefficient and difficult to manage. With large volumes of 
tests for any given project, manual processes yield errors that 
can be avoided by applying configuration m;Lnai,'ciiient prac- 
tices to the test development and mainteiKiurr [tnM isyes. 
(Justoinizable tools such as CaseWaie/C M aie available to 
help control these processes. TLMS allow^s us to improve 
and automate test development and maintenance, as well iis 
establish a formal test reuse program. 
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Implementing and Sustaining a 
Software Inspection Program in an 
R&D Environment 



Although software inspections have become a common practice in the 
software development process, introducing the inspection process and 
sustaining and measuring its success are still challenges. 

by pJean M, MacLeod 



lliape iB not much disagreement in the industry about the 
value and benefits of software inspections. However, die re's 
nioip to impiementing a software inspection program than 
training moderators ajid creating forms. Tliis paper discusses 
how thc^ software inspeetion program was implemented af 
HP's Patient Caie Monitoring Systems Di\ision, wiih empha- 
sis on how the program is sustained and how its success is 
mcaijured. 

One thing we leanie(i while miplementing and sustaining an 
inspection program is that it must be managed with a clear 
organizational o\\^er and a champion (chief moderator). 
The process nmsl be flexible enough to withstand ctiange:^ 
and imp rove me nLs without compromising tliose things that 
tlcfme formal inspections such as prepaiation, inspection, 
rework, and so on. Tiie in^plementation is really an evolu- 
tion that needs tailorinj^ to the culture and en\iroiunent 
while keeping the fundamental process intact. 

We have conducted over 85 inspections at our division. Data 
hiLS been collected and jnaintained in a database from the 
very beginning so we could anal>^e how well die process is 
working. Besides data about the process itself, we keep data 
about the rework perrormed after each inspection, including 
the tjjne to fix defects and the cause of each defect. The 
clause data helps us look at the software develop luenl 
process and identify ai'eas for further invest igatioiv and 
improvement. 

Background 

A formal software inspection process was introduced to our 
division aliout two years ago to increase the efficiency of the 
defect detection jirocess axKi ultimately shorten the time to 
market for key products in the division. From our historical 
data on softwme projects, we know^ that it takes an average 
of 20 hours to find aiid fix a defect <letecled diuing the testing 
phase of a project. We also know Hi at finding and fixing de- 
fects earlier in the developmeni (not -ess takes less time. The 
prohlcm we had was to introduce software inspections into 
the software development process tis |)airilessiy as possible 
to gain acceptimce of the process and start collecting data 
that would prove the value cjf the jjrocess. 

We modelled our inspection process after a method that uses 
clearly defined process steps: kickoff, preptuation, defect 
logging nieeting, causal analysis, rework, and follow-up.^ 



Kickoff. Tliis step is used to h;uid out tlie materials for the 
inspect ion J assign roles to inspectors, and ensure that eveiy- 
one iu\derstands the purpose of the inspectitm as well as 
when and where the defect logging meeting will be held. 
This step can be done in a meeting or by electronic mail 

Preparation. Tlu^ preparation step is critical to tlie sticcess of 
every inspertjon. This is when inspectors review iuid check 
the document* on their own, noting any defects to he logged. 
The objective is for all Inspectors to work independently to 
find defects so that they will come to tJie defect logging 
meeti!ig (irepj^ued to report their defects. 

Defect Logging Meeting. Tliis is the time when all inspectors 
conu^ togi thcj' to review the document and report iu\y de- 
fects I hat were fomid. During this jueeting a defect log is 
maintained hy the moderator. The meeting is facilitated by 
the moderator and shoidd last no longer than two hours. 

Causal Analysis. Tlie purtiose of this step Is to review tfu'ee to 
live m^^jor defects that were fomid during the defect logging 
meeting to determine the most likely <::auscs for the defects. 
The causal iuialysis is done at the end of the defect logging 
meeting mici involves biainstonning causes of the defects 
aitd possible actions that could be taken to prevent those 
defects froni occurring again. 

Rework. Rework is performed by the owner of the document 
thai wiis inspected. Tlie owner is rtH|iiired to Ox all defects 
and take appropriate action to ensure that every item logged 
during the defect logging meeting is addrcsseti. Tlie owner 
also assigns a defect cause code to every defect. 

Fol low-Up. In this step tlie moderator checks mtli the docu- 
ment owner to determine if all defects logged during the 
defect logging meeting were addressed. T\w mtjderator also 
collects and reports all ajjpropriate inspection metrics duriJig 
Uiis step. 

Our chief moderator was specially trained and then charged 
with implementing the software inspe<*tion jjrocess in the 
R^D lab. Although the process was modeled after the steps 
mentioned above, we have made moditlcations to the process 
that we felt were necessary^ to facilitate acceptance of tbe 
process in our orgtuiization. Our first goal was to start using 
inspections with one project, and then leverage Uiat success 

' TTiis includes arctiitecture teumerrts. specificatlofli design docymsnts, and radt lisltngs 
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to hejp gain acceplaiR^e of inspections as a way of doing busi- 
ness in R&D. We alscj consfantly looked for ways to miprtA e 
the inspection process to increase the effecth^eness and 
efficiency of finding defects. 

Implementing the Software InspcK^tion Program 
Gaining Support. It is imponani lo gain the proper support 
and acceptance whene\' er a new program is introduced, hi 
the c^^ of software inspections, the impact is felt across 
the entire R&D organization, and therefore it is very impor- 
tant to involve as many people as pt>ssibie when tiying to 
gain support and acceptance for the program. 

hiitially, the inspection process was accepted by one project 
team, uicluding the project titanager. They were ready, able. 
and \^iihng to use inspecrions in al! phases of the project, 
beguming with the aichiiecline documents and continuiiig 
through specification, design, and code, h was importaiit to 
gaui acceptiince from the project manager so liiat time 
couJd be allocated in the project schedule for inspections. 
Because the entire team had accepted tJie idea, we fomid 
that most inspections were verj^ snccessfiil and showed a 
ver>' large return on tlie investment for the time spent by the 
team in preparing for and iJarlknpating in inspections. 

WTiile one team was targeted initially as the pnmary user of 
inspections, other teams were also encouraged to conduct 
inspections by their software <4uality engineering team lead- 
ers. The selling pjocess was much less fonnal ;ind relied 
priniarily on die soffwfire quality engineeiing team leader ftj 
gain acceptance trom the jjroject team to do inspections. 
We foimd that this process was not as successful in gaming 
the acceptance required to make Inspections a success 
throughout the R&D organisation. 

In one instance, we had data that showed that one project 
team was nt>t getting a ver>' high rt^tun^ on investment from 
the inspectiofis they were holding. Ulien we aiialyited what 
w^as going on, wt» found that the team had never l)eeri given 
a presentation on inspections and didn't undeistmid die pur- 
pose of inspections. We found that reviews were l>eing lield 
before tlie actual defect logging meeting to clean up the doc- 
ument l)efore the insptn'tion took place. As a result, defet^t 
logging meeiir\gs were held thul found no criticiil, serious, or 
medium defects: only vvry lovv-level <iefecis were fount I, 
Once we determined wiiat seemed to be the root cause of 
the problem^ an overview session was held with the team to 
explain the j)uri>ose and benefits of instJections. Inspections 
held after the jiresentation showed sume improvement but 
more work needs to be done to detemune other causes for 
the low return on mvestment. 

All project teams must be given tiie same message about the 
purpose of inspections and they must have acceptance from 
project managers so thai tiie ]jrf>per lime will he yJ lowed for 
prei>aration and participation in defect loggir^g nieeliugs. 

Chief Moderator, Tlie chief moderator is the most important 
person when it t*omes to implementing and sustaining a soft- 
ware inspection program. It is tlie moiletator's responsibility 
to make sure that the process is being followed conectly 
and to watch for' vmiat ions in the data thai wtjuki indirale a 
problem or a need for impjovement. The iiutJoitimte of this 
role catuiot he overstated when it comes to implementing 
and sustaining the ijispe cation progrant. 



Initially, the chief moderator acted as a champion for the 
inspection process, gaining acceptance from nuuiagement 
and project teants for the process and putthtg the pieces in 
place to ensure that the process was followed m the same 
w^ay l>y all participants. This involved developing forms cus- 
tonuzed for tite site and \\Titing a guide that could be read by 
anyone to help uriderstajid the iitspection process. The next 
job of the chie^oderator was to help other modemtors 
learn how to moderate inspecdons by observing them as they 
conducted defect log^tg iueetings and acting as a ctiach. It b 
important thut the process be followed as (consistently its 
possible. Having the c*iiief moderator coach otlier moderators 
helped maintaui the consistency of the inspection process. 

The beginning stages of implementing the inspection process 
required constiuit attention by the chief moderator. Once the 
process was in place and the other moderators had been 
trained, the role of chief niotlerator was reduced to one of 
custodian, that is, anaJy/ing the il^e data to find pattents that 
might indicate a problem. Although the role of the chief 
moderator has changed since we introduced the inspection 
pi-ocess, our exjierience shows that without the constant 
w^atcltfulness of the chief rnrjfierator the process wiU get out 
of control and thie benefits of inspectioiis will suffer 

Getting Started. Our initial inspections were performed on 
test scripts written by software quality engineer in the divi- 
sion. This allowed moderatore to practice moderating and 
inspectoi-s to see the process in action before it w^as used 
with project teams- Some of tfie bugs in the inspection fonns 
were worked out and minor improvements to the process 
were made dining tiiis time. 

Some shortcuts were taken to get the program started. We 
decided to go fonvard with inspections in spite of not having 
standarfis and cliecklists in place for every^ type of dtjcu- 
ment. We recognized tliat creatu^g standards and having 
them at^cepted by ertgineers as st^uidaicls for writmg docu- 
ments and code would take too long. Although we have 
some stiUH lards and ( heeklists in place, w^e still don't have a 
comt)leie .set. It remains a goal to develop standaids for all 
of the different types of documents. 

We aJso decided not to implement the causal atialysis step of 
the inspecfion process during die itiitiid phase of introthicing 
inspections. Asking inspectors to slay on al I he end of a two- 
hour meeting to ilo a causal analysis would increase resis- 
tance to particijjating in inspections. Now that the process is 
in (ilace, we have recently started performing a causa! analy- 
sis of three to five mi^jor defects at. the end of eveiy inspec- 
tion. These limited causal analysis meetings are possible 
because inspectors are rujw familiar with the process and 
the defect logging meetings tend to be shorter. As with any 
change, however, it has been slow^ to take hold and it will 
take time to recognise the benefits of the causal analysis 
meetings. 

Tliis has proved to be a successful model foi' implementing 
inspections. It was very useful to ]iractice doing inspections 
luitl make minor unprovements before taking the program to 
the project teams. Wlien the task of creating standards and 
checklists seemed too laige and threatened to |>revent the 
Ijrf^gram from getting cjff the groimd. we foiuit^ il more usehil 
to keep moving foi^ard in spite of not having all the tools in 
place. We also fell that eliminating the causal analysis stej> 
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Fig. 1. AvenigL* inspection times by dor;uiiieiit type, 

helped lower resistance to rhe new process and fticilitaled 
its acceplaiice by project teams. AIJ uf these slioiicnis lielpetl 
us get Uie program off the ground and have insj u^rr jt ms si art 
to take on a life of their own. 

Sustaining and Improving the Process 
Collecting Metrics. Metrics have been collected from the very 
beghmiiii^ of our inspection program to enable lis to mea- 
sure the process and (.[lumtify ihe benelits of inspections. A 
Microsoft® Excel ilatabase was tTeated to maintain the 
data Data is collected from every inspection and includes 
the type of document inspected, the m!ml>er of i>ages in- 
spected, the number of defects fotuid, defect severities, and 
the amount of time spent preparing for aod pariicipating in 
the inspection (see Fig. 1). This data lielps us analyze how 
the inspection process is working. Average inspection effec- 
tiveness (defects per page), inspection efficiency (hours per 
defect), and retimi on investment are monitored to help us 
determine the overall usefulness and value of inspections 
(see Fig. 2). 

Elvery defect fomid during an inspection must be resolved 
by the author of the document (or the engineer doing the 
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Fig, 3, inspetlidn defect causes, 

rework). The le worker must assign a severity^ level to each 
defect and, usitig standard cause cotles, assign a defect 
cause code for every defect that is fixed, Tlte iunouni of 
time spent domg ah of tile rewor k is also noted. This data is 
maititiiined in the inspection databctse and analyzed to deter- 
mine the most frequent causes of defects found during in- 
spections. We have found that design defects iue the most 
common tjpes uf defects (hscovered w itli inspections (see 
Fi^. 3)/f^ A further breakdown uf the tyqies of design defects 
is siiowTi in Pig, 4. A more thorough analysis of tins data in 
cor\jtutction witli the root-cause analysis data being collected 
at the end of each inspection should help us detemiine op- 
portunities for improvement in the software development 
process. 

Inspection metrics are also used to help sell tl)e process to 
new^ project teams. We are able to show the results of every 
inspection held in the last two years and prove the useful- 
ness of the process to the most skeptical engineers. We now 
have enough data to help other engineers imd projet I man- 
agers estiniaie Ihe itmoimt of time to allocate for ijust>e<*tions 
based on the type and size of ckjcunients (see Fig. 5J. 

We continue to collect data and look for new ways to ana- 
lyze it to help us detemiine where to make improvements in 
the process, 

■ Although we did not initially do the catisal analysis step of the mspectmn pfccess. we did 
ftiqwB each rewarker to iclaritify sis best rhey could the tausg of every detect they fixed. I his 
it tha data shtwn in Rg. 3. 
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Fig. 4. Design defects by stibt^ato^gon,-. 



Fig. 2. Inspection data by d<»ciiinent type. Tlus data is intended to 
help detemiine the effectiveness of the inspection process. 
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Fig. 5. Average hours per page by document. Each of these tirnes 
includes preparatiuti, defetr logging, and rework time. 

Intangible Benefits. We ran'l talk about the benefits of inspec- 
tioas wiihnui mentioning the intangible benefits, which are 
benefits that are hard to ineasure and quantify. For example, 
we have changed one of the rules for condticting Ihe defect 
logging meeting by allowing limited fJLscassioTis abonl defects 
when necessary. These discussions are allowed if fhey lead 
to a better imderstanding of a defect or explain how some- 
tiling works. However, disciLssions about style or how to fix 
a defect are not permitted. We have fotmd that the increased 
communication, tiie transfer of knowledge, and the improved 
teamwork are some of the intangible benefits from these 
discussions. Inspectors leave the inspection feeling that they 
have gained something as weU as given somethmg. 

Managing Process Improvements. All of the data collected is 
tised to measure the inspection proc^ess and lr>ok for ways to 
improve it. It is importatit for the chief Dioeierator aitd other 
moderators to be vigilant abonr tlie data from inspections 
and to look for opportunities for improvement. All of our 
moderators meet periodically to talk about what is working 
imd what is not working. It is easy for the process lo break 
down and lose some of it.s effectiveness. 

We have found that analyzing the data over time is usefuJ to 
show lis whether our process is getting better or worse. For 
exam pi e^ when wc looked at the effectiveness and efficiency 
data points metiticmed above at three-to-four-nionth inter- 
vals we saw tiiat inspections were not ;jls effective at finding 
defects as ihey were when wc first starteci doing inspections 
(see Fig, 6). As a resuh, we have recently laimched an in- 
spection improvement project aimed at determining why 
our effectiveness and efficiency are dropping and what we 
can do to reverse the downward trend. 

Defect Prevention. As mentioned earlier, when inspections 
weie originally introduced, we decide*! nut to include the 
causal analysis step of the process to facihtaie acceptance 
of the process. tUtimately. however, lite goal of softw^are 
inspections is to lielp j)['everil defects from occuiTing again 
in the process, W'v are tu>w trying to collect data on h(}w 
some of the defects found fluring inspectioiis could have 
been prevented by doing a causal analysis at the end of each 
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hj ' Hours for Each Ircsjioction 

i\ = Defects Found During Each Inspection 

n = NumtiBr of Inspections Conducted During a Particular Interval 

Inspection Hours = Total Moderator Huurs + jKickoff Meeting Hours x 
Nitimher ol Particifiants} ^ Total Preparation Hours + (Defect Logging 
Meeting Kciur^x Number of Participants) 4- Rework Hours 

Defects - Critical Sefious. and Medium Defects 

Fig. 6. Soflvrsie inspection trends. The calculation of each of these 
dats points is liased on the total number of defects^ inspeclioo 

[loiirs, and inspectioris tiiai <)ecur wirhin a particular inten-^aL 

mspection. We select tliree to five of the major defects that 
were reported during the defect logging meeting and try to 
get to the root cause of the defect by asking why it occurred. 
Over time we hope that w^e will accumulate enough data to 
help tis pinpoint areas in the development process that need 
improvement. 

Conclusion 

Tlie softivare inspections (irograni at HPs Patient Care 
Monitoring Systems Division has been vei^ successful We 
know from our data tliai sofi ware inspections are a much 
more eft u lent way of 11 ruling dt^fects than testmg software 
at the etid of tite developittenl process. We alst? know^ that 
we are getting a better rettirn oti investment for our inspec- 
lion hours [>y investing them in inspect ing the architecture, 
speci neat inn, aji<i tiesign <iocuments for a prrxiuct, rattier 
than the 1 radii ional approach of insjjectuig only cotle. 

Ac k no wie dgm e n ts 

Palsy Mcolazzo is the chief moderator and primary imple- 
ment or of the software inspection program in the R&D orga- 
nization at our division. It is because of her cffort-s that the 
program has been so successful. 
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The Use of Total Quality Control 
Techniques to Improve the Software 
Localization Process 

By implementing a few inexpensive process improvement steps, the time 
involved in doing translations for text used in HP's medical products has 
been significantly reduced. 

by John W, Goodnow, Cindie A* Hammond, William A. Koppes, John J. Krieger, D. Kris Rovell-Rixx, 
and Sandra J, Warner 



Text is a nu^jor clement in the huTiiyii iiiLeriat'e of rliagnostic 
ultrasound imaging products niaiiufactLired at UPs tniagiitg 
Systems Division (ISY). The ultrasound systt^ms, which dis- 
play real-time two-dimensional images of the analomy, also 
display measurement and calculation labels, operator 
prompt messages, lielp screens, and anatomical annot:atlon 
text (Fig. 1). 

Regulatory requirements of ceitain countries stipulate that 
medieval ei)uipment sold in these c^ountries must be localized 
with respect to software and hardware text and relatt^d user 
d ocnme ntati on. 

Even where regulatory i-equirement-s do not stipulate lan- 
guage ^ a re<]uirenientf it can be a competitive advanta^ge to 
have a localizeci product availalile. 

ISY introduces new products or revisions of existing proti- 
uds at international medical conventions, where potentijiJ 



customers from all around the world see English-langnage 
product demonstrations. However, there is usually a large 
time delay h etwee n English-language and localized proditcl 
availability, Tliis can result in lost sales opportunities, hi addi- 
1 ion, some internat ional sales contracts specify a financial 
penalty if a product is not delivered on schedule. 

Localizing the softwaie lext in a prtxiiict requires a signifi- 
cant engineering effort. Engineers niusit design the English 
product J provide documentation for the translators, imple- 
ment the t ranslat ed text, and assist with t he lajiguage verifi- 
eation and software validation testing. It is prudent to make 
the time spent doing this localization work as efficient as 
possible. 

This paper describes how Total Quality Control (TQC ) was 
appheri to the softw^u-e localization at. our division to reduce 
the time required to localize en^bedded software text used in 




Fig. 1 . A screen from an HP 
SON OS phasf^d array imaging 
system. 
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Z. WIrv Selected 

Qf^^A^ss the timfi to matfcgt fur aTf Incal language ref esses, 
vihich increases cu^iomer satisfactiop and reduces the costs 
associated with iTBRsilion ^\^ns outside of the U.S. 

Btriu cfis efT^titteerii tq tcsoyrces requtfe d for foealizatloii. 
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3. Beginnitig Status 
Efapsed Time by TfaitsJsiion Step 



Average Time for 150-String Project 
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Steq2 Transialion 

Step 3 Create Language 
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Fig, 2, PaneJij for the first [)arl at the TQH st.cir>h£>arri for the Koft- 
■w^iw. t mnsiation enliaiiceiTieiii projefM. 

our iiif dical diagnostic ultrasound sy stents. At Hryl we 
t houj^hl thai much of the delay in the iocaJixation process 
occuncx! in tlit* translation stef>. By using TQC we discov- 
ennl tliat wc I'ould teduce delays in areas originally l hi slight 
( o he Ijeyond the control of the RM) lab. 

The TQC Technique 

The nine major stages of t,he TQC prDCess improvement 
model are: 

1. Issue 

2. Why Selected 

'1 Beginniiij^ Status 
4 Analysis 

5. AclifJtis 

6. Result.s 

7. ProblenKs Remaining 

8. Standardissation 

9. Future Plans. 

We applied these nine steps to the issue of software 
localization. 

The IssEie. Our first step was lo chocjse an issue and iVjniiu- 
late a concise issue statement. A TQC issue stateinent must: 

• Indicate a change or diret*titm 

• Have an indicakjr of qualily m a product or service 

• Declare the process or operatioti involved. 

The ia^ue siatement for our project is shown in Fig. 2a. 



Why Selected. This stage should state why the issue was se- 
Iccied, 11 should show that benefits can be gained by making 
improvements and conversely, that undesirable results will 
twciit if the process condnues unmodified. Fig. 2b shows 
rlie output from this siage for our project- 
Beginning Status. Before begLnning any changes to a process, 
the status of the current process must be understootL We 
first listed all the details involved in the current localization 
process. From these numerous details, we abstracted five 
m^or steps from the ciurent process (see Fig. 2c). 

The actions performed during this process include the 
following steps: 

• Step 1: Create a LOLA file. The localization engijieer ex- 
tracts the English text from the source file and sends it to 
the translator in the form of a LOLA file* LOLA, which stands 
for local language, is an IIP Vectni PC-based internal soft- 
ware tool for translation text entr^-. In LOLA, the translator 
sees the software tex1: as isolated text strings. 

• Step 2: Translation. Tlie translator translates tlie text strings 
to the local language using LOLA. The translated text is sent 
back io the originating di\ision for implementation. 

• Step 3: Create language software. The trtmslated text is en- 
coded info software and memory chips (ROMs). The proto- 
tyi^e system ROMs are then dehvercd to the translator. 

• Step 4: Language veriOcation, The translator verifies the 
translated text on a prototype produtn. During tliis step, the 
translator sees the text in its proper context and can verify 
that the wording Ls appropriate for the context. The transla- 
tor sends corrections back to 1 lie localization engineer at 
the originating division. 

• Step 5: Release. The localization engineer corrects tlie lan- 
guage software text, quality assiu-ajice j^erforms final soft- 
ware validation, and manufacturing releases the localized 
products for shipment. 

Because tlitie w^^.s tlu^ indicator in our i,ssue statement, 
we class ifi*^<l ilu^ following lliree diTferent time process 
performance measures (PPMs): 

PPM-1: The calendar time required for each of the five 

steps m the localization process 
PPM-2: The calendar time fiom the EnglLsh language 

release to the loeal language releases 
PPM-3: The number of person days of R&D effort 

consumed during each step hi the locahzation 

process. 

To de ten nine the time required for om* cuirent localizalLan 
process, we ev^iluated several recent localization projects 
based on these PPMs. The average size of tliese projects 
was 150 softw^are text strings (see Fig. 2c). 

Analysis. Dining this stage we UBed brainstonrting techniques 
tc> iuifdyze firevious prryecls to dett^nnitie where time was 
spent.. To promote aji open and noi^int imidating atmosphere, 
we followed these tyiJical brainstonuing guideUnes: 

• All ideas are perniitt.e<l willi one person speaking at a time 

• Evaluation and discussion of i<leas is postponed until later 

• Questiotis are a.skefi only lf> t larify ideas 

• After all ideas are pres^ented, the items on the list are 
clarifietl to he sure they are uiiderstot^d by ail 
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4. Analysis 

Text i^ frozen very la te, delaying the start of ttie trans I at ion process. 

Local taiigiiage releases liave law visibrlrtv and are poorly ntanaged, 

Lacal language releases are otters given low prior jty. 

Not enoi/gli cammynication with \he translators. 

Translation toots used by R&O are poor (significant manual nKart rnquireil). 

H&P doesn't ilevelnp inxt with translation in ntind. 
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5. Acifor^s 

H 

Stabilize text and sfnrtthe translation process earlier m the tfevelopment 
cycle. 

Increase the visibility dHranslatinn activities by proviitirtg regular status 
updates. 

Incorporate translation activities into ibe project management documents. 

Work to establish a better "team" relationship with the translators, 

Dnvelop better translation tools. 

Provide software development guidelines Ear text. 
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G. ResuJts 
Elapsed Time by Translation Step 

B eg i nn in g B ef o re TQC Afte r TQC 

Revision Average Revision 1 Revision 2 

ISO Strings ^ Strings 245 Stiings 




Stepi St«||2 Step 3 Step 4 Slep 5 
locaHzation 
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Fig. 3. Piirtels for the second part of the TQC storylK:^ard for the 
software translation enJiariceiTieiit projectH 

Several m^jor items pertaining to ISY procedures were 
found from these brain storming sessions: 

• Preparing the originiil EIngU.sh LOI4A file required many 
hours of nianuat effort to cut and paste text front the source 
code into the LOLA file. This process is tedious and error 
prone. 

• The product devehipment schedule did not provule enough 
Ume for locahzat ion activit ies. As soon as English was re- 
leased engineering resources were dedicated to higlier- 
priority projects. Localization was not a formal item in the 
product s release protocol. 

• Most engineers at our di\%ion had km English-focused view- 
point and did not realize that certain design considerations 
aie needed to make fhe softwiire text local izjible. Also, 
since no one was given the responsibility for localization, it 
was seen as someone else s job. 



• Messages iji languages other 111 an English typically require 
betw'een 3(T^^i and T^Wn more text characters. Often, the design 
of the original English text cUd not take ll^ int.o account, 

■ Syntax in languages other than English is typically different. 
Sometimes engitieers would construct text messages from 
individual translated wf^rds iLssiuning that the syiUax was 
universal. This resultetl in nonsense localized messages. 

• No attempt was made to stabilize software text before 
English release. Engineers continued to tnake text c^hanges 
until final testing had liegun. Tlie translators either had to 
wait until the Enghsh product w^as released to begin, or they 
began earlier but had to revise the text numerous times. 

In addition to the m^or if ems above, we also identified 
many smaller process items that involved our interaclions 
witii the translators. Fig. :Ja summarizes all the issues found 
ill the hrainstonuiug session. 

To better evaluate why these items occurred » we created 
several cause and effect diagrams, also called "fishbone'* 
diagrams bec*ause of their \isual similarity to a fish skeleton. 
We found four m^jor categories in whic^h time could he lost: 
process, communications, people, and tools. The categories 
are drawTi as branches off the backbone of t he cause and 
effect diagram shown in Fig. 4. 

Each of these categories was liranctied lutiJier imtii root 
cattses were identified. P^ach fishbone diagram highljglits 
the causes for the step being addressed, which in this case is 
step 2 (translation). 

Initially we created fishbone diagrams for Step I (create 
LOLA file) and Step 3 { create language software) because 
each required a laige anioimt of engineeriiig lime ;yid they 
were steps over which w^e had control We believed that 
R&D liad little control over Step 2 (tratislation), btJt since il 
tot)k the longest time, we diagranuned it. 

The fishbone diagram shown in Fig, 4 revealed some impor- 
tant issues. Since we do not have exclusive use of scarce 
translation resources, we must be on time In delivering 
translation materials to the translators. If we are late in 
sending our translation materials, the transtatoi-s work on 
tasks from other HP divisions. We can keep oiLr plat^e in the 
work queue by giving more accm-ate dates to the translatois. 

Low estimates of the number of text strings to be translated 
were another cause of <ielay. The translalom schedule their 
time based on the estintate we give them. If we under<:^sti- 
mate thenumher of strings, our text caruiot be tnmslated in 
the lime allotted. Tlie translators then spend a lot of time 
juggling their projects to find time to translate the extra 
strings. 

Our estimates of the nimiber of strings were low- because 
when the scope of the project increased, we ditl not update 
die estimate. 

Poor communication between the translators and om* tli vi- 
sion led to many small time delays, which together had a 
large impact on the inniaiomid time. 

.\fter creating the fishbone diagrams, we tied the root 
causes to tlie PPMs mentioi\ed above. Tlus gave us the in- 
siglit needed for the next stage: developing the appropriate 
action plan. 
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Actions. Wc held aii other brtimstorming session to gather 
ideas to address riie root causes of the flelays. This residted 
In a list of thirteen sjjeririe action items which were evalu- 
ated for impact, eflbd , and the amomit of control we had 
over the action item. We also identified owners for the action 
items- Fig. 3b summarizes the main themes of the action 
items. 

The following list ties the main themes of the action items 
to the problem they solve and the process performance 
measures (PPMs) that are impacted: 

Action: Stabilize text and start the translation process 

earlier. 
Problem: Text is frozen ver>' late, delaying the start of the 

translation process. 
PPM: 2 — ^Ei^glish-to-laiiguage release time 

Action: Include translation activities in project manage- 
ment documents. 

Problem: We often give local language releases a low 

priority and thus they are poorly numaged and 
have low visibility, 

PPMs: 1, 2, and '^ — elapsed time for each step, Enghsh- 

to-Ianguage release rime, and the number of R&D 
person days consumed 

Action: Establish a better team relationship with the 

translators. 
Problem: Communication 
PPMs: 1,2, and 3 

Act i c )! I : I nvestigate the development of our translation 

fools. 
Problem: Signitlciinl uiiuuial cffoil is required to convert 

l>etween LOLA and the source code. 
PPMs: 1,2, and 3 



Action: hivestigate software development guideUnes for 

text string design. 
Problem: English text must be reworked to function with 

translations. 
PPMs: 1,2, and 3 

Results. After we generated the action plan, we began ad- 
dj^essing the action items. This resulted in the followmg 
im\i<)r chimges to our localization process: 

• In striving to release localizeti protlucts earher, stabilization 
of text has become a priority for software developers, 

• The visibility of the translation activities has increased. 

• Conmiimication witli the translators hiis improved, as has 
our credibility with them. By workmg as a team with the 
tnmslators, we have improved commimication and reduced 
lumaroimd time. 

• Software development guidelines for handling localization 
have been established, published, and distributed internally. 

Next, we evahiated the effect these actions had on oiu- origl- 
riiil goals by exiunining two localized product releases that 
occurred durir^g the course of our activities. Fig. 3c shows 
PPM'l (elapsed time between process steps) for the two 
product releases compared witli the begiruiing average data 
from Fig. 2c, Revision I was before taking the actions listed 
above, while revision 2 shows the effects of the actions. 

As we collected the data to generate the graph, we found that 
our PPMs were Hawed. We did not have a good mechanism 
for scaling the results based on the number oJ' text suiiigs, 
Obviouslyj revision 1 , which contained approximately 50 
strings, would lake a shorter period of time to locaUze thaii 
revisiun 2, which contained approximately 245 strings. 
Desphe this problem, it is still apparent that our efforts have 
significantly reduced the times for steps 2 and 4. Because 

[cantJOLied on page 699 
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Tools for the Language Translation Process 



The software translation enhancemerit project described in the accompanying 
artde jdentiHed rhe need to reduce engineering time requjrerf to prepare lext for 
iranslatron and integrate translated lext into the product PartiaUv aytofT>aimg the 
preparation and tntagration of local language lext through the use of new devel- 
opment tools reduces inconsisienctes between languages and trees valuable 
engineering resources. 

Current Process 

The current tfanslation process is based around LOLA, or focal language software 
tooJ, which is a PC-based application used by HPs medical products divisions for 
language translations LOLA requires that fiies be in a special format, consisting of 
general information (such as revision, language, context}, format specifications. 
and translatable text. The engineer responsible for localization manually converts 
a source file containing texi to the required LOLA format. Converted files are 
mo^ed from a workstation to the PC and sent to the translators Translators using 
LOLA transEate the files to the local language and return the translations to the 
originating division. The engineer then moves the hies from the PC to a work- 
station and imanuaJiv converts the translations to. source code. 

Requirements 

The requifemerits identified by the TQC team for automatic handling of local 
language translations were: 
" A unique text file format must be specified that will hold master English text and 

associated local language translations. The text format must be C-like in its con- 
struction and must contain all the' information in a C source fife as well as the 
information in a standard LOLA file. 
> English and local language text fries must be placed under ravision control. 
* The tools must automatically generate: 

English LOLA fries from master English leKt file^ 

English C source files from master English text files 

Local language text files from local language LOLA tiles 

Local language LOLA tiles from local language text files 

Local language C fifes from local language texi hies 

A file reporting differences between two different versions of a text file. 

Text Format 

With the above requirements in mrnd, a file formal was specified. Formats and 

global information take tfie lorm of functaons. The name of the funcunn indicates 
the ionaai to be set and the function argument indicates liie vafue of the format 
le.g , iustifyf CENTER);). Gtobal formats, such as character sets and fonts, are usualfy 
software platform dependent, and are contatned in the construct globatf }. Text and 
formats to be interpreted as translatable are contained in the construct string{ ) 
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C source code that logically belongs in the fife can be Included outsrde these 
additional constructs and will not be interpreted by the tools, A typjcal string 
definition is as follows: 

string { 

si3:e(4, 50); /* max si2b - 4 lines, 50 chiars each V 
capftalizedllME); T capitafize first word of line V 
iustifytLEFTf; /* left justify text 7 
const ctiar 'const User_def msg- { /^'user message that*/ 

"Enter a comment to descrfhe the", /'appears on displayV 
"LDDP (up to 16 characters}:", 0); 
descnption(Dialog box prompt that appears when the user 
selecis 'Manual Entry' from The store dialog bojt. The 
user Is ahfe to type in any IB-character string to 
describe the file to be stored. OKAY and CAMCEL buttons 
will appear below the message. The user selects OKAY 
when satisfied with the comment or CANCEL 
to select a comment tram the list instead,]; 

} 

Lacalizaticin Tools 

The following locah^atton tools were created to pertoriti the required file conver- 
sions, calculate differences between revisions, and transfer files tn and from a 
translation database. Fig. 1 shows the environment in wh<ch these tools run. 

• newtflj^tfile This program generates header and global tej<t information for the 
part icu tar so It ware environment, 

•t0xt2hex, hsj(2text, and hex2c These tools perform the hie conversions specified in 
the requirements 

• taxtdiffs This IS an mteraciive X Windows application. When an Encjhsh fde is 
cfianged, the engineer uses tfiis program to generate the LOLA database fifes. 

• readyloclang This program transfers any fifes in the saufce tree to the LOLA 
database and checks the consistency of that database. 

•transferfocfang. This program moves LOLA files from the LOLA database to the 

PC server, ft afso pots the files m DOS format. 
■ racejveloclang This program nrtoves LOLA fifes from the PC server to the 

development worfistation 

• loisfc Thts program runs on the PC. and depending on the parameters sent to it 
transfers LOLA fifes between the PC server and the PC 

The foflowing scenario in conjunction with Fig. 2 shows the tvpical fife of a text 
fife using the localisation toofs. 

1 A new English text file, which has been pfaced under revision control, is converted 
to hexadecjmal and pfaced in a LOLA file. 

2 The LOLA file is added to the translation database automahcalfy by rtadylocfang 
when the database «s readv for translation. Readytsdang wiSf inform the user it 
textdiffs needs to be run on the tile. 

3 The LOLA files to be translated are transferred to the PC and archived. 

4. The archived fife is sent to the transfators via e-mail for translation into ttie 
focaf language 

5. When the translators are done, the file is returned (via e-maifl unarchived, 
transferred to the PC server worlrstation. and then moved to a development wor*:- 
station. This re suits m a local fanguage LOLA fife containing a reference to the 
English revision of the tBKt file from which it was derived 

6 The origlnel English revision of the text file and tfie LOLA local fangifage file are 
used to create the local language te)(t file. 

7. The locaf language text fife is checked in and C source code is automaticalfy 
generated 

Wtren engineers revise an English text fife, the process js slightly more comp fl- 
oated The engmeer uses tejadiffs to create the necessary LOLA fifes for the data- 

base Teiftdiffs allows the engmeer to match strings interactively that are the same 
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between two revisions of the file. When the translator first ItmkFi at 3 matched 
line of text, the transJated text h-om the previous revision will be shown. 

Conclusion 

The scheiTiB outlined above helps to reduce ihe chance of ir^consistencies between 
languages. Since all translated files refer back to Enghi^h, comments, text fornials, 
and code (other than text external to the additional constructs) are idemicat in all 
languages. Having a single fde format to maintain ensures that changes to an 
English text file are earned through to the English LOLA file and the local language 
text file immedEately after a change. Software testers use LOLA reports showing 
all the text to help thein verffy the operation of the system ^ These reports can be 
made available soon after any changes, reducing redundant defect reporting. 



Embedding the format and comments in the text fife centralizes documentation. 
Previpusly, the documentation was disseminated through the C file and ttie LOLA 
file. Having only a single file formaE to keep under revision control provides easier 
tracking of changes 

Ultimately, the new tools and processes wiN reduce the engineering resources 
required for translating to local languages and improve the quality of translated 
text. 



George Rom 

Software Design Engineer 

HP Imaging Systems Division 



our action plaji t[id not specifically address the R&D-inteixsive 
cutting antf pasting jirocess, steps 1, 3, ajid 5 ciid not improve 
significantly. 

Problems Remaining. Although we were able to achieve a 
signitlcajit degree of success, we did not solve all of the lo- 
calization issues we discovered during analysis (see Fig, 5a). 

Standardization, The TQC process should lead to the devvl- 
oprnent of standanls, Slandards help tf> maintain a process 
atid provide a platfoiiti from which to cotifinue !o build 
(see Fig. 5h). 



We developed three standard documents, T\\e first of tliese 
documejits. the Trajislation Status Memo, is published 
monthly This document helps maintain high visihility for 
translations anrl cU^arly communicates chanj^es to the 
schedule. The .secoiKl doeumetil, the Division Release Plan, 
details the features mui protlucts scheflulerl fcjr release iu 
upcoming months. This document has been updahni lo in- 
clude both focal cUtd f^nglish language re fe;Lse thUes. kisfly 
the Guide for Creating Transfatabfe System Text has been 
pubfished and distributed fo the software development staff, 
imd is a hving (jorument in our software environmeni. 
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7. Problems RBmiimnDji 

LocalizaiiDn toolsei is rieliited bul not impiemented, 

Projeci management documents siill need to be updated. 

The relative priority of lacalization versus new feature development is stitt 
an issue. 

"Idle time" jtime lost between IranslatiDn steps) needs to be ttccotinted for 
betlar in the process model and I hen measured- 



(9) 



S. Standardizetioii 

Trans iatton Status Meino putilislied monthly by the translation coordinator. 

Release Plan updated to mclude local fanp^ge releases. 

Guide for Creating Translatable 3YSitm TeKt publistied and distributed 
internally. 



m 



9. Future Plans 

Update the Product life Cycle to better address translation related activities. 

Implement the LocaJizatipn Tool Set 

Continue to colle£lJiiMflQ.9 ragarding localization time associated wiift new 
releases. 



[g) 



Fig* 5, Panels for the third jiart of thi? TQC sipi^bt>ard for tlie soft- 
ware translation enhanf:om{^n! project. 



Future Plans. Ttie final stage in the TQC process is geiieratifig 
phms f(jr liie future (see Pig. 6r). We plaii to update our 
product Life cycle process, aiicl continue to collect metrics 
on local language releases. 

In addition, we plan to collect metrics on a new localization 
tool set, w4tic h Ls design IjO improve our efficiency in handling 
English ajid translated text (see "Tools for the l^anguage 
Translation Proress"" oi) page 68). This tooiset will obviate 
the need to cut and paste, and will automate nimiy of tlie 
other steps hi tlte localisation process. Without our TQC 
efforts, we would not have been able to justify the high cost 
of implementing these tools. 

ConcliisLon 

Our group, although luUrained in TQC metJiodologies, suc- 
cessfully applied TQC principles to a real problem. Even 
though w'e focused on tlw results ratlier than Oie process, we 
learned a lot about the process. We were able to scale the 
use of TQC so that the process thd not overshadow^ the |>rob- 
lem at hand. In addition, we identtfied causes of problems 
that may not have been micovered with an utxstnictured, ad 
hoc approach. 

Given the positive experience we had with TQC metliods 
tiuring this project, we will enthusiastically and confidently 
use it again. 

Ac kno wle d gm en ts 

The authors would like to thank Paul Kelly for his encour- 
agement and advice in the writing of this article. 
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A Transaction Approach to Error 
Handling 

The transaction-based recovery concept used in databases can be 
applied to commercial applications to help provide more reusable 
and maintainable programs. 

by Bruce A. Rafnel 



Commercial programs contain hvo major paths: a forw^ard 
path that does the work and a reverse path that roUs back 
the work when errors are detected. Typically, these patlis 
are so tiglitiy bomid together that both paths are difficult to 
read. Code that is difficult to read results in code that is 
difficult to write, debug, enhance, and reuse. 

For example, in the object-oriented progranuning method- 
ology, one reason why objects are not as reusable as they 
should be is that they are tightly boimd together at the error- 
haiidhng ieveL Many tinies error codes even give chies about 
how an object is implemented. 

The sohition is to handle errors in programs as they are han- 
dled in a database transaction* recovery n^echanisrn. In a 
database transaction, the transaction eittier executes in its 
entirety oi; if an error is detected in any of its operations, it 
is In tally canceled as if it had never executed. If an error is 
found, ail work is automatically rolled back to the beginning 
of the transaction- 

Error Handling 

Software developers have sometimes been dismayed by how 
difficult commercial programs are to maintain and design, 
compared to programs they developed in school Someone 
typically points out that programs developed in school were 
"toys," which assumed perfect inputs and hardware witii 
unlimited memoiy and disk space. In addition, most software 
engineers have very linle formai traming in errorhancinng 
methods, Tyjiically. software devplopers learned error fian- 
dling by example or by trial and error, and they use the tradi- 
tional error-handling model; check for an error, fmd an error, 
and return an error code. 

Many formal design processes* such as stnictured analysis 
and stnictured design, recommend tJiai errors be ignored 
diuing design because Uiey are an implementadon detail. It 
seems t hat this implementation detail can take up to one 
third of the code in commercial programs. This is not just 
code added aroimd iilgori thins, but code placed diret*tly in 
tile middle of the a]goritJnn.s. The resulling programs are 
difficult to read, debug, and reuse, 

' A database transaction is a unil af work rhat invalve^s one or more opera !m^^s oti. a database 
For GxampSa. che bperaimn of tnseriing data in ilw database could be a transactiDn tf its the 
only upsratiori performed tf the mssrt is combined with gn update, both opflrations wmild be 
considered one transaction. 



Exception htmdhng, or error handling, has a large academic 
Ijase and m^uiy of the ideas given in this paper are probably 
Jiot new. However, most of the ideas presented here are 
based on 15 years of obsenations mid experiences with a 
lot of gootl feetlback from experienced programmers. This 
paper will describe a progranunuig style that separates most 
of tJie error-handling process from the maui algoritlmis. 

Mixed Forward and Reverse Path Problem 

The two m^jor paths in coinmercia} programs are shown in 
Fig. L The forw^ard path is the path doing the work that 
the program is designed for Tlie reverse path is the error- 
handling code needed to keep the forward path working 
correctly. It does this by detecting problems, fixing them, 
and rolling back partially completed w^ork to a point where 
the algorithm can continue forward again. 

TVamp Error Problem 

Often an intermediate fimction in a prognun has to stop what 
it is tlomg m the mid<lle of the algorithm i^ecause a furTi/tion 
it called cannot complete its designed task. This can lead to 



Forwunf Path 



Reverse £nror Path 






- Funcuon A 
Setup 

Validate Inputs 
Call Fur^ciion C 
Validate Res^uH^ 
Call Fiinctfon E 
Validaie Results 
Return 

' Function B 
Setup 

Validate Inputs 
Call Function C 
Valtdet« Result 
Operation 
Valiifate Hesults 
Return 

Function C 
Setup 

Validaie Inputs 
Operaliun 
Validate Results 
Return 



Fig. 1. Traditional error-handling prograin flow. The^ forward path 
f loea the work of the pr^:>gra^l aitd l\w reverse patli dor^ti the error 
handling. Notiit? that error-haiifilijigcode is dispersf^d Ihroiighout 
the aJgorithm, 
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Error Definition 

Jn the accompanying arncJe errors are not detects Errors are excepttons thai a 
particular algarithm is not designed to handle Defects are errors that are out of 

the design limits o! a whole application or system. 

For example, many afgnrithms are designed with the assy mpt ion that there is 
unlimited memory When there is not enough memory for the algorithm to com- 
plete successfully, this is an efior A whole application must be designed to handle 
these out-of-memory en-ors. If an application does not handle these errors and the 
program halts or the program behaves \w an undocumented way. this is a defect In 
other words, errors are relative in that they depend on what level of the software 
h iera rchy i s bei ng observed , 

Error handhng consists of four main parts: detection, corredion, recovery, and 
reportjng. Error recovery is the mam focus of the accompanying article. 



""Iranip errors.'"* Tranip errors are erroiB iii functions that 
are not directly related to the current function. 

Tramp eiTors are the result of a real error ocnirnng in a 
lower-level fi^nction. For example, function Af) calls function B^J. 
Function Bf) needs some memory^ so it calls the mallocO rneitiory 
aJlocallon fu taction, Tlie mallocf} finiction returns an oiti-of- 
memory error Tliii> is a real error for l.he mallocO fiLticlion. 
Function BO does not know liow to gel more tnemory, so it has 
lo stojj and pass the error l>a(^k to function Al). From the per- 
spective of function BO aiKf i)robal>ly function A(), an out-of- 
memoiy error is a tran\p error. 

TVanip errors prevent functions from being the black boxes 
they were designed to be. In l\w above example, notice that 
function AO now knows something about how^ function BO is 
implemented. 

TVainp errors ore really part of enor recovery aiid not part of 
eiTor detection because if the real errors could be corrected 
immediately, tramp errors would not occur. 

Unreadable Code and Poor Reuse 

Mixed forward mid leverse pal Its ;md tramp errors combine 
to obscure the main forw^aid path of the progr^iin, which is 
doing the real work. Tlie corret tit^n and recovej*y parls {)!' 
error handling aie tlie main areas tliat obscuie tlie code. Most 
of the detection and reporting code csxi be put in separate 
fimctions. 

Because of tramp errors, almost every function has to htuitlle 
errors generated by all lower-level functions called This can 
cause light data coupling which make^ code reuse more 
dilllcuh. 

IVatii^action Error-Handling Solution 

To solve the above problems, two things need to he done: 
separate the forward prtK^essing patii from the reverse enor- 
processing path and use context independent error codes. 
This method of error hatuliing Ls ver>' similar to the way 
datal>ases handle error recovery. Transactions tue used to 
control the rollback process when a group of database 
operations cannot be completed successfully. 

' Tha term tramp error is used because it is mnf smilgr tij tfie tramp data x&m used in 
structured arta lysis and structured design ^ 



Separate the Paths 

Tlie traditional defensive way of prognmunmg is to assume 
that a fimction may have failed to complete its designed 
task, resulting in a lot of error-handiing code lo check for 
the errors ai\d to roU l>ack partially completed work. This is 
what we have in Fig. 1. 

Reverse this ^issumption and ass tune that retuniing func- 
tions have completed their designed tasks successfully* If 
the fimction or any of the fiinc lions it calls has errors, it will 
pass processing control to a recovery jjoint dellned by the 
prograjimier In other words, transaction points are dellited 
so that if there are any problem:s, tJie work will be rolled hack 
to those points and the processing will proceed fonA^ard 
again. 

With litis approach, there is no need lo cheek for errors after 
each function ctill, and the fors^'ard patJi is not cluttered 
with tramp error^ietection code. Only error-detection code 
for real errors remauis, and most ot the error-conection and 
recovery code is clustered aroimd the beginning and encl of 
the transactions (see Fig. 2). 

Because enors are processed set>aralely from w^here they 
are detected, the error codes need to hold the context of the 
error. 

Context Independent Error Codes 

Error codes that provide more uifomiatlon tbaii JLLSt an error 
number are context mdependent error codes, hiformation 
such as w^hat function gene rate tl the error, the state tliat 
caused the enor^ tJie reconunended correction, and the error 
severity must be encoded in the error code so that it can be 
corrected in a location separate from the forward processing 
patJi. 

Lisiialiy cr.>nlexts of enors are encoded for error-reporting 
functions. For example, the names of the program, function, 
error t^pe, mul error code are saved and repotted later. 
However, sophisticated encoding schemes are rarely used 
because with traditioiral error handling, the context of the 



Forward Path 



Reverse Error Path 



— --FunEtiofi A 

Begin Traiisactlan 
Setup 
Validate Inputs 

Call Function C 

Call Function B 

End Transaction 



■- Function B 
Setup 

Validate Inputs 
Call Function C 
Dparation 
Validate Result 
Return 

k 

■-Function C 
Setup 

Validate Inputs 
Operation 
Validate Rasult 
Return 



Fiff, 2. Tr-rinsaction eiTor-han<l]i3ijg iirogran; flow, 



72 J uiw 1 WS Hewlptl rac kard J nu n inl 



)Copr. 1949-1998 Hewlett-Packard Co. 



error is alreatly knov^ii because checking is done right aft**r 
a ca]] to the offending function. 

With transaction error handling, the recovery process is 
separated front the forward processing path so context 
independent error codes are required. This may involve the 
creation of unique error codes across a whole appUcatton 
or sj^ein (witJi the codes bound at compile time). .\n alter- 
nath^e would be to assign code ranges or other unique 
identifiers to functions at mn time. 

Code Readabilltj^ and Reuse 

The transaction approach malces programs easier to read 
because the reverse error process paths are vij^ually sepa- 
rated from the forward process paths. 

The transaction error-handling style niakt^s it possible to 
create some general error-recovery interfaces so that func- 
tions (modules or objects) will onJy be loosely comiected at 
the error-handling level. This is possible because the number 
of tramp errors used to r<mt roi tht^ recovery process is 
reduced and only the real errors need to be handled. 

Implementatioii 

The following are sonte ideas about how to start develophig 
a transaction enor-himdling libraiy. The list is not exhaustive 
and there are some problem areas, but it does offer some 
concrete ideas for l>iiilding a transaction error-handling 
mechanism, 

IVans action Control Management 
Some language support is needed to implement the mecha- 
nism tltal controls error recovery. Languages like HPs Pascal - 
MODC'AL have a try/recover feature Uiat can he usefl t.o siip|>cu1 
a transaction error-handling style. Tlie trv/recover statement 
defmes error- recovery code to be executed if ati execution 
error is detected within a particulai' area of a program. Fig. 3 
shows the flow of control for a try/recouBr statement. 

For other languages a feature usually called a ''glol^aJ goto" 
must be used. This feature allows a lower-level function mid 
all olher functions above h lo exit to a point defined in a 
higher-level fimction wit ho tit passing error-code flags 
through all the oUier functions, [n C this is done witli the 
setjmp and longimp library roinines. The setjmp function saves 
its environment stack when i! is c^alled, and longjmp restores 
tlie environment saved by setjmp. The examples given later in 
this article are written in C and show how^ these functions 
are used. 
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Fig. 3, The control llov,' for a try/r(?(:ovor sULerncnt, 



The new C++ exception-hai^dhng feature^ prondes an excel- 
lent foundation for a transaction-based error handler Refer- 
ence 3 also describes how to add C++ error-handling ftmc- 
tions to regular C programs. However, overuse of the C++ 
exception-handling feature could lead to code that is just as 
clutrered as the traditional error-handling st^le. Transaction 
boundaries for objects must be designed with the same care 
that goes into the design of an object s interface. 

If the langiiage is missing a global goto (or multithreaded) 
feature, macros or other wrapper* functions can be used to 
buUd recovery' processes that are mostly Ln\isibk\ Wrapper 
fiinctjons are described in more detail later 

Some of the features ihat might be considered for a 
transaction error-handling package include: 

• Allowing nested tran^ctions by keeping the transaction 
begin points on a stack 

• Allomng fimctions to share a common transaction stack 

• A J lowing fimctions to defme their own transactions with a 
conmion transaction stack or allowing fmictions to define 
their own transaction stac k for special cases 

• Defining special transaction points to handle errors in 
common categories [For example, abort the whole pro 
gnmi, restart the whole progiam, close all files and restart, 
close cunent file and restart, and release aU memory not 
needed tmd restart.) 

• Making pro\Tsions for the transaction error handling lo be 
lurtied on and off (Wlien it is off, a function retmiis error 
codes in the traditional way.) 

• Defining expected errors for some fmictions by masking out 
the errors neetled, (This feature can be simulated by turning 
off transaction error handling, but then imexpected errors 
will also have to be managed ) 

Transaction Data Management 

Recovery involves more (hai^ just rolling back functions 
because tliere may be son\e intermediate work that nee* Is to 
be undone. Tliis may involve releasing lumeetletl memor>^ or 
changing global variables back to the values they had at the 
beginning of the transaction. 

Memorv. Memory is best managed with a mechanism similar 
to the mark/release memor>' fciiturc piovided in some iinple- 
menlations fjf the Pas( al programming language. T\w mark/ 
release procxxiures allow ilynajuic aHocatior^ kuul deall<Jcation 
of memory in an executing Pascal program. 

The C language functions malfocf} and freel), in coi\iunclion 
with a stack of pointers to keep track of the niemory allo- 
caledj i>rovide the best features for aUo eating i^u id freeing 
niemtJiy, Willi these features, a mark functitin can be called 
just before the program transaction's start point to lUiirk the 
current slack point. If a longjmpO goes to this recovery point, 
a release function is called to free any memory allocated 
after the mark point. 

A commit function, whic h indicates the successful comple- 
tion of a trajisaclion in the database context, is needed ai 
the end t^f a program tnmsaction lo remove pointers from 
tite mark/release stack* Nested tnms actions, however, need to 
he considereri. A simple solutioji woukl be to have each 
transacLion keeti its own mark/re tease stack- 

• Wrapper functaarii (or macros) are used ro add tijr>£rionaliry to eKisting funclions iha^ cannot 
tje changed je.g., tibrary tunctiansj, 
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Globals. Global variables (and other static variables) can be 
rolled back with a strategy similar to the memory nianage- 
n>ent problem. Just before a transaction's begin point the 
states of ail tiie globals tJiat might he changed in a transaction 
are saved ot\ a sta<"k. This allows transactions to be nested. 

Context indepeEident Error Codes. The traditional error- 
handling style of (iiecking error codes after each fiiiif Tion 
call automatically gives errors a context. The transar!i(tTi 
error-handling style needs to provide this context infomiation 
in another way. 

The biggest challenge here is that error codes alone are not: 
veiy useful. For example » 97 could be the letter "^a" (ASCII 
code), the digitis "6** and ^1" (BCD formal), index 97 into a 
message array^ the 97th error, an out-of-memory error, a 
disk-full error, a clivi de-by-zero error, and so forth. 

To decode an error code the source of the error miis^ be 
known. Some information that may need to be saved when 
an error occurs includes the machine name, program name, 
process numl>er, module name, fimction name, and of 
course, the error code. This information needs to be sent 
only when it is necessary to roll back a transaction. 

The amount of information that has to be saved is depen- 
dent on the location of the transaction recovery point and 
the nm-time environment. For example, a client-server 
application may need more information than a sim|>le PC 
apphcation. Each recovery pomi can usually find higher- 
level context, information fairly easily. For example, the 
names of the mat^hine, program ^ module, and function can 
easily be passed down to a lower-level recovery point. How- 
ever, lower-level context information cannot be collected 
because the function Uiat. had the error would no longer be 
active- 
Implementation Summary 

The following are some points to consider when bnplement- 
ing a transaction error-handling scheme: 

• Put the rollback points (if any) at the beginning of functions 

• Put en or detection and defatilt substitution at the beginning 
of functions 

• Put some error-detection code in the middle of functions to 
check intermediate values 

• Put error-detection code at the end of functions to validate 
the results 

• Do not put error-handlmg code for managing rollbacks in 
the middle of a fimction. 

Examples 

Traditiofial irror-Handling Style. The following example pro- 
gram, which reads a tMnar^' fonnatted file, is coded with a 
common error-handling style. The ct>de would have been 
more cluttered without tiie aExitErr(l and aRetErrO macros to 
manage the error reportmg and recover^'. This example uses 
the simple error-recoveiy process: detect enor, report error 
and exit. However, notice how much error-handling code is 
mixed in with the algorithm. 



read.c - Read b binary formatted file 

This program reads and prints a binary file that has the 

following structure; 

Record type code (The last record has a value of 0) 
Size Number of characters in Msg 



puts(pMsg); exilfpErr) 
puts(pMsg); retum(pErr) 



Msg 0to204S characters 
Record type code 
Size 
Msg 



#define aExitEfripMsg^ pErrJ 
#define aRetErripMsg, pErrl 

typedef struct! 

long Type' 

int Size; 
} aFileHead; 

Forward Algorithm: 

Main 

T Open the file. 

2, Call the Read process. 

3. Close the file. 

mainOi 
int Err; 
RLE* InFiJe; 

if [(InFile ^ fopenr file.bin", "rb")) ^= NULL) ( 

aExttErrfError Could not open; file. bin". U; 

} 

if[(Err-aRead|lnFile))3=0}{ 

a£xftErr( "Error: While reeding: file.bm'*, 2); 
} 
if(fclose(lnFile}i 

aExitErr|"Error Closing: file. bin", 91; 
} 
irmainO*/ 



if {(Msg = (char *) maltoc(204e}) == NULLK 

afletErr( "Error: Out of memory "^ 3); 
I 

RecNum-OL; 
while (1){ 

if (fseeMpHandte, RecNum, SE£K_SET) < 0) { 

aRetErri"Error: in fseek", 4); 
1 

N = fread|[char*)&ReeHead, sizeof(aFileHead), l.pHE 
iffN<OK 

aRatErrrError: in fread", 5); 
}elseiffr^!-lK 

aRetErr("Error: shortfread",6}; 
} 



V 
V 
*/ 
t 



*/ 
*/ 



/* Fo rwa rd AJ g o rith m c o ntin u ed: 


■-!?'• 


r 


t 


r Read Process 


't^' 


/* 1. Read the Type and Size values. 


'W 


/* 2. lfType-0. exit 


^f. 


/* 3. Read Size number of characters into the 


'f 


/* Msg variable. 


f 


r 4. Print the Msg. 


:^. 


r 5. Goto step 1. 


*r 


/* 


^ 


int aRead(pHandle) 




FILE* pHandie; 
{ 

int Err, N; 






char* Msg; 




long RecNum; 




aFileHead RecHead; 





ndle): 
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ifffiecHead.Tvpe-^OLU 

) 

if (RecHeadSize) f 

if f(N - freadlMs^, RecHead.Sae. 1, 
pHandlel) < D) | 

aRet£rrf"Error in fread", 7); 
}elseif(Nl^1}( 

aRetErrt "Error short fread''.8h 
I 
ifKEiT^aPrinltMsg, 

RecHead,Size)M=0){ 

aRetErr("£rror; in aPrim". ErrJ; 
} 
J 
fiecNum = RecMum i- RecHead.Size + sizeoftaFileHeadJ; 



) 



iraReadO*/ 

Transaction Error-HandMng Method. The following listings show 
aj) inipleinenTation of the transaction error-handling sT>-le. 
Tlie fin^l lixSting sliows the program (transaction) readx rewnt- 
ten to incori:)orate the transaction error-handling st^^le. The 
other listings show the support functions for the transaction 
error-handling ni eth od . 

Notice in the main body of the algorithm f iiai li^e ctide fol- 
lowing the recovery sections is clearer than file iraditiorial 
error-handling example and there is no eiTor-liaiidliiig or 
recovery code mixed in with the algorithm. 

There are some obvious shodcornin^s in the support mod- 
ules. For example, most of the niacroy should be fimctions 
and the vEnv values should he saved in a tinked list, 

A number of engineers have pointed out that tlie transaction 
implementation of readx Ls not really shorter th^m tJie tradi- 
tional implementation of read. c because the enor-handling 
code was simply moved out of read.c imd put in the support 
functions. But that Is exactly the goal: to remove tbe en-or- 
handiing code from ni<ist fiuiclions Jind encapsulate the en-or- 
handling in comjiion shared code. 

The Main Program. Tiiis program performs 1 fie same function 
as fhe read.c program given abcn'e. However, ii has been 
recoded to use the transaction styie of error liandling. The 
functions erSet^ er Unset, and erR oil Back provide the en or han- 
dling and mv de fined in the include tile erpub,h, wtiich is 
describt^d below. 

The inchide tile epuh.h contains wrapper macros which are 
cSefined so that the a^>propriate transaction error-handling 
functions are called in place of the standard library function. 
For example, w^hen the standarrl fnnction fctose is invoked, 
Hie function eClose is actually' (.alleff 



r 
r 
r 
r 
r 
r 
r 
r 
r 
r 
r 



r&ad.c - Reed a binary formatted file 

This program reads and prints a brnary file that has the 

following structure: 

Record type code {The last record has a value of 0) 
Size Number of characters in Msg 
Msg to 2043 characters 
Record type code 

Size 
Msg 



typed et struct { 




long Type; 




int Size; 


} aeeHead; 


r 




r 


Forward AlgurEthm: 


r 




r 


Main 


r 


1. Open ttie fife, 


r 


2. Call ttie Read process 


r 


3. Close tfie file. 


r 




mainO{ 




RtE* InFile; 



erHecOn = 1: 

if (erSet(J) { /* Transaction rollback parnt */ 

printff" Error: %d in function: %s\n", erErr, 
erPun): 
erLfnsetO; 
exild); 
} r End Recovery section */ 

InFife =fopenr'fi!e.bin", '*rb"): 
aRead(lnFile); 

fcloseOnFile): 
erUnsetd; 
}rnialn()7 

r Forward Algorithm continued: 

r 

r Read Process 

/* 1. Read the TypeandSizevafues. 

/* 2. If Tvpe - 0, exit. 

r 3- Head Size number of characters into the 

/* Msg variable. 

r 4. Print the Msg. 

/* 5. Goto step!, 



int aReadjpHandle) 
RLE*pHandlB; 



char* 

long 
aPlleHead 



Msg; 

RecNum; 

RecHead; 



7 
7 
7 
7 
7 
7 
7 
7 



V 
7 
V 

7 
7 
7 
7 
7 



linclude "erpub.h"' 
#include ''epub,h" 



Msg = (char *l mallocjcaMsgLen); 

RecNum - OL; 
while 11} { 

fseeMpHandle, fiecNum, SEEK_SET); 
fread((char *) SRecHead, sizeoflaFileHead), 1, pHandIa); 
if(RecHead.Type^^OU{ 
return;/* EOF 7 
} 
rf(RecHead.Stze){ 

freadlMsg, RecHead. Size, l.pHandle^; 
aPrintffv'IsQp RecHead.Size); 
} 

RecNum = RecNum + RecHead.Size + sizeof(aFileHead); 
} 
}/*aRead(S7 

File erpub.h. The macros ai^d global data structures defined 
in this tile form a crude error tratisaction manager The 
following operation.s are perfonned liy these rruicros: 

• erSet. This macro adds a rollback point to ttie vEnv 
( envirotnnent ) star :k. 

• erUnset. This macro removes the top roUback point Oram 
tht^ vEnv stark. 
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• erRollBack. This macro saves the fimrtion name and error 
code in a global area f erFun and erErr}, and if the erRecOn flag 
is true, control is pa^ssed to the roUhack point defined on tlie 
top of the uEnv stack. If erRecOn is false, erRollBack wiU simply 
return the usual error code. 

Remember that these macros are for illustration only. ThuSj 
there are no internal checks for problen^s, and Ihe global data 
structures should be defineii as static values in a library mod- 
ule or collected into a structure 1 hat is created and passed to 
each of the transaction error-handling functions. 

/* erpub.h - Error Recovery Public Include file */ 
imclude <:setjfnp.h> 

/* Private VarJabEes*/ 
#define vMaxEnv 5 
jmp_buf vErv[vMaxEnvl; 

int vLevel = -V, 

/* Public Variables*/ 

#define cerFunNameten 32 

Idefine erSet(( setjmp(vEnu[++vtev©l]| 

Idefine erUnsetO — vtevel 

Idefine erRollBacMpFun, pErr, pRetl \ 

slrncpylerFun, pFun, cerFunN3meLen);\ 

erFunlcerFunNameLen-ll = \0; \ 

erErr - pErr; \ 

if(erRecOnMvLevel>-0)f^ 
longjmp{vEnv[vLeveli pErr); \ 

}else{\ 

return(pRet); \ 

} 
mt erErr - 0; 

char erFun[cerFunNamelen]; 
int erRecOn = 0; 

File epub.h. This file contains ^\Tapper macros that catise the 
timet ions defined in the file e.c to be calle tl in place of t-he 
standai'd library functions. The functions in e,c will behave 
the same as the standaid library fm\ctions, but if the enor 
transaction manager is on (erRecOn is true in erpub.h), control 
will be passed to the last defined rollback point, rather than 
just returning the same error code as the associated standtird 
library fimction. 

Using these wrap}Der macros makes it easier to add trans- 
action error handlmg to old programs, but if it is desired to 
make the errorhtmdiing process more \asible, the functions 
defined in e.c would be called directly instead of the standard 
library f mictions. 

Tills file is also a good place to define context mdependent 
error codes. 

/* epub.h - Error Ubrary Wrapper Macros I only a few are 

shown here) */ 
#define ceEOF 1 

#define ceOutOfMem 2 
#define ceReadErr 3 
#define ceReadShort 4 

#ifndef vInE 

^define fclosejpStreamI eCbse(pStreaml 

#defire fopenipRleName, pTypel eOpenlpFileNamSr P^VP^) 

#define fread{pPtr, pSrze, pNltem. pStreamI \ 

eHeadjpPtr, pSize, pNltem, pStream) 
#define fseeMpStream, pOffsel, pPrtName) V 

eSeeklpStream, pDtfset, pPrtNamel 
#!iefine maiioclpSize} eMallocipSize) 

#endif 



Rfe e,c. This file contains die implemenlations of the v^n^pper 
macros defined in epub.h. Only two of the fmictions are 
shown in tJie following ILstiug, Notice that these functions 
behave exactly like the standard librarv^ functions with the 
same name be< ause they call the staiidaid hbrary fmictions. 

For more flexibility, a real error transaction manager might 
allows the user to define the error codes that determine 
whether or not a rollback occurs, 

/* e.c - Error Library Wrapper Functfons (onty a few are 

shown here) */ 
#define vtnE 
#include "epub.h" 

void^ eMalloc(pSize) 

sizej pSize; 
( 

void * Mem; 

if {(Mem = nialloc(pS[ze|) ^ WULL) { 

erRoflBackCmalEoc", ceDutOfMem, Mem); 

} 

return(Mem); 
ireMallocV 

size^t eReadlpPtr, pSiza, pNltem, pStraam] 
char* pPtr; 
sizej pSize, pNltem; 
FILE* pStream; 

i 

size_t Num; 

Num^freadlpPtr, pSize, pNltem, pStreamI; 

if (feofi pStream I) { 

erRollBacM'ffead", ceEOF, Num); 
}elseif(Num<=0]{ 

erflollBackriread ', ceReadErr, Kftirtil; 
}else if (Num <pNltem){ 

erBollBacMlread", ceReadShort, Num); 
} 

return(Num); 
ireReadV 

Conclusion 

VMien transact! <:»n error handling was introdnced on a proj- 
ect, engineers initially resisted removing IF statements after 
calls to fmictions using transaction error handling. After 
seeing how much easier the code was to write and read, the 
resLstiince faded tmd engineers started setting up their own 
transaction recovery points. 

It would seem that debugging code using the transaction 
error-handling style would be difficult. However, experience 
has shown the debugging time to be a littie better than the 
debugging time for a tradition;il error-handling style. This 
decrease in time can probably be attributed to less em- 
bedded error-liandling code, causing defects to stand out 
more. Also when error-handling code is added, it is added in 
a structiu-ed way that distiu"bs very little of an already de- 
bugged program, Tliis supports the way most engineers 
traditionally like to code. 

So far this error-handling style has not been used on aay large 
projects, but it has been used on small programs and func- 
tions written for eniiancing old programs. One of the nicest, 
features of this style is that it can be used independently of 
other error-handling styles. 
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In suiTiinar>. a transaction error-handlmg style can lead to 
the following benefits: 

• More reuse because error handling can be separated from 
the algorithm so tlial the coupling between functions Is 
looser 

• Improved code supportability because it is easier to read 
the algorithm and see what happens with errors 

• Better code quality- bei^ause there are fewer error-handling 
statements in the main algorithm, so the code is easier to 
read and the defect-s stand out 

Just as the functional parts of algorithms am being separated 
from iLser interfaces (client^server models), error handling 
can also be separated from the functional algorithm. 
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Rajesh Lalwani 

A software engineer at the 

Commercial Systems Divi- 
sion, Rajesh Lalwani joined 
HP in 13B8. Hewasborn in 
Mandsaur m the Madhya 
Pradesh state of India. He 
received a master of tech- 
.. nology degree in computer 

"^ science from the Indian 
Institute of Technology, New Delhi in 1986 and an 
MSCS degree from Pennsylvania State University in 
19B8, In the past, he enhanced and maintained com- 
mand interpreter software and components of the 
MPE operating system kernel. More recently, he de- 
veloped a procedure for parsing IVIPE and POSIX file 
names and a directory traversal routine. He's currently 
worltrng on symbolic links lunctjonality and device files 
for MPE/iX. Rajesh is the author of several POSfX 
articles, has presented a number of conference papers 
on the same topic, and is working on a hook on 
POSIX 1 His outside activities mclude tennis, watch- 
ing classic movies, and staying in touch with his 
wife, who IS finishing her medical degree in India. 

47 Preventiog Software Hazards 

Br«afi CannollY 

^p^h Brian Connolly is a project 

W ^\ manager far software quality 

■"ff , £*^ e ng m ee r I ng i n H P s Patie nt 

1^^^^* Monitoring Systems Division 

^^^KKr and has been with the com- 

^ H^ y pany since! 984. Pre vi ou sJy, 

h e de ve f oped rea I -t i me soft- 
ware systems for Raytheon 
Corporation and Westing- 
fiouse Corporatjon Since joining HP, he has worked on 
tBaHime software development for a bedside monitor- 
ing application, object-oriented software development 
in a clinical information system, and software quality 




engineering for several bedside monitor and central 
reporting station products. He has written several 
papers related to hazard avoidance and software 
quality and testing for internal HP publrcation He's 
also a member of the IEEE His educational back- 
ground include a BS degree in physics and engineer- 
ing awarded by Loyola College in 1977, and an MES 
degree [19B3) in digital systems, also from Loyola 
Brian is marned and has two children His leisure 
activities include running, swimming, woodworking, 
and coaching youth soccer. 

53 Configyration Management for 
Tests 



Lei^nard T. Schroath 

With HP since 1985. soft- 
ware quality engineer Len 
Schroath worked at ttie 
Log[C Systems Division and 
the Colorado Springs Divi- 
sion before moving to his 
current position at the Boise 
Printer Division He's the 
author r coauthor of s i x 
papers for HP conferences related to software quality, 
testing, and reuse. Len was born in Detroit. Michigan 
and attended Brigham Young University, from which 
he received a BS degree in computer science in 1985 
He is married, has three small children, and is a 
coach at his local VMCA. He also enjoys music and 
sports and officiates at basketball games. 
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Jean M. MacLeod 

A native of Arlington, 
Massachusetts, Jean 
MacLeod studied elementary 
education and sociology at 
Emmanuel College tn Boston, 
Massachusetts, and received 
a BA degree in 1971. She 
has worked in the software 
quality field since 1974, ini- 
tially m several small to mid-sized companies before 
joining Apollo in 1987. At Apollo, she was responsi- 
ble for initiatmg a software inspection program in an 
R&D lab. She joined HP's Corporate Engineering Soft- 
ware Initiative in 1991. and contributed to the improve- 
ment of software inspecbons for the Patient Care 
Monitoring Systems Division at Waltham. She's now 
working on software process improvement with other 
divisions in the Northeast. Jean is a member of the 
Society of Women Engineers. She has two teenage 
children and enjoys golf, racquetball, and reading. 
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iohn W, Goodnow 

A section manager at HFs 

ftlmag^^g S^ie^Tss Division. 
Jofin uDodnow joined HP m 
1983 stiortfy after recetvir^ 
I 1^ a BS degree in efectrtcsf 

engineering from the Univer- 
sity pf Pefmsylyama. He 
earried an MS degree in 
etectrjcal engineering in 
138B from Stanford University through the Honors 
Coop program His firsi HP projecis included work on 
HP Page Writer efectrocardiographs and ultrasound 
sysiem software, and he continued work on ultra- 
sound software development as a project manager 
and now as a seciion manager, John's professional 
interests include computer and system architecture, 
operating systems, and image processing Bom in 
York. Pennsylvama. he is married and enjoys board- 
sailing, skiing, woodworking, and vacationing an 
Martha's Vineyardl 

Cindie A. Hammond 

Cindie Hammond has been 
with HP's imagmg Systems 
Division smce 1989 Born in 
Nassau, the Bahamas, she 
studied computer science at 
the University of Utah, from 
which she received a BS 
degree the same year she 
started at HP An REiD soft- 
ware development engineer, her professional interests 
include ultrasound imaging and image processing. 
She's a member of the ACM and tutors mathematics 
at a bcaf efementary schoof. Her outsfde activities 
include softbalf. boa rrisai ling, drawing and painting, 
and renovating her home. 

William A. Koppes 

Bill Koppes was barn in 
Mnrristown, Mew Jersey 
and studied electrical engi- 
neenng ai the University of 
Washington at Seattle 
[BSEE 1976) and at the 
University of Calrfornia at 
Berkeley (MSEE 19781. At 
Berkeley's Donner Labora- 
tory he aJsn developed positron emission tomography 
and rBconstruction atgorrthms. He joined HP's Imag- 
ing Systems Division in 1978, where he first was a 
hardware development engineer and then a software 
development engmeer. project manager, and section 
manager Now principal engineer at the Advanced 
tmaging Systems group, his proJesSfonal mterests 
include medical imaging and clinical diagnosis, soft- 
ware ilevebpment, and R&D management He h 
coauthnr of a paper related to digital signal and image 
processing and has actively participated in several 
professional conferences. Bill is married, has a son 
and daughter, and enjoys composing and perfornT<ng 
mtisic. 
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John Kneger foined HFs 
Waltham Division in 1974. 
where he worked on the 
-^ ^ ^ J digital hardware and ^jft- 

j^^^m ware design of tf^ HP 
'^^SH^H 4721 M capnometer After 
^^'^^H moving to the Imagirvg Sys- 
^H terns Oivisi0n/he contrib- 
^^^ uteri to the software design 
and develrjpmer>i for the HP SON OS VDO and lOOG 
cardiovascojar imaging systems. He's now specie I iz- 
mg in diagnostic ultrasound imaging He's the author 
of two previoii-s HP Journal articles related to the HP 
4 72 IDA capnometer, and has presented papers at 
two HP software engineering productivity confer- 
ences. He IS also the mventor of a patent related to a 
help facility for the HP SONDS TOO Bom m Santa 
Momca, California, John received a combmed bache- 
lor's and master's degree in electrical and biomedical 
engineermg from the University of California at Los 
Angeles m 1973. He is married and has two daugh- 
ters. Active in his church, he enjoys acting in commu- 
nity theater and is renovating his home, an 1850s 
vintage New England farm house. 

Dan re I Kris Rovell-Rixx 

OKrls RoveJI-Rixx has been 
with HP since 1990 and is a 
software development engi- 
- neer at the Imaging Systems 

Division Previously, he de- 
signed and implemented 
real-time software for auto- 
mated test equipment and 
fuet controls for jet aircraft 
at the Hamilton-Standard Division of United Technol- 
ogies, He also worked for Ashton-Tate, and for a small 
manufacturer of IBM PC peripherals Born in Miami. 
Florida, he completed work for a 8S degree in engi- 
neering (computer science emphasis) in 1979 from the 
University of Florida and an MS degree in engineering 
management in 1987 from Western New England 
College. He^s a member of the ACM and the IEEE Kris 
rs a sailing enthusiast. He and his wife have sailed in 
the Virgin Islands and Windward Islands, and in 1992 
he. was a volunteer for Sail Boston '92, a parade of 
tall ships He's a [so an amateur radio opergtor (call 
sign WX1ZI and enjoys all types of music, 

Sandra J. Warner 

Sandy Warner joined HP in 
1984 as a clinical applica- 
tions specialist in the Mid- 
west sales organisation and 
IS now a globatizatton spe- 
^ J^H ciahst in the Imaging Sys- 
ytfl^^l temsDivisian.Herprofes- 
>' ^^1 s^onal interests m elude 
^^^ market research an customer 
ntjeds, sureign language translations, and ISO 9000 
coordination. She was horn in Rochester, New York 
and has a BS degree in laology from The Ohio State 
University i197e) Before loining HP she managed a 
mobile cardiovascular testing service for a diagnostic 
service organization and before that she managed a 
diagnostic lab for a medical center Outside of work, 
she teaches asironamy for an HP- sponsored school 
science program, and likes skiing, carpentry, land- 
scaping, and backyard harbecue extravaganzas. 
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Bruce A. Rafnel 

^^^^^ tware development 

^^B^^^ -: g I neer Bruce Baf nel f^s 

m ^^^ worked m the H&D fatos at 
W ^ '^'^P ^^9^^ ^^ divisions since join- 

"' i "^ ^^^ company's General 
E ""^^fc Systems Division in 1381 

K ^^iPH His contributions include the 
development of software for 
the HP 150 and HP Vectfa 
personal computers and working on the dictionary 
team for the HP 3O0O and HP K)DO compoters, He^s 
now in the Professional Services Division A graduate 
of California Polytechnic State University at San Luis 
OhrspD, he received a BS degree in computer sctence 
in 1991 . He's a member of the IEEE and the C Users 
Group, and includes document management systems, 
computer graphics and image processing, object- 
oriented programming, and neural networks as pro- 
fessional interests. Bruce is married and has a young 
daughter. His hobbies include home automation with 
voice control. 
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Mark H. fJotess 

^0f^^ ^3''^ Notess was born in 

£^ ^^ Buffalo. New York and 
jL^fg^P^H studied English and teaching 
'El k jJJ English as a second language 
%^^^Jm ^^ Virginia Polytechnic Instr- 

^^^^^^^ tu te a n d State Un ivers rty. He 
^^^^^^^^H received a BA degree in 
^^^^^^^H English en 1979 and an MA 
^^^^^^^^^^ degree in education in 1381. 
He was an instructor at the University of Alabama 
and later was a programmer and instructional designer 
at the Virginia Cooperative Extension Service before 
completing an MS degree in cortiputer science, again 
from Virginia Polytechnic Institute, in 1 988. Since 
joining what is now HP's Open Systems Software 
Division the same year, he has designed, imple- 
mented, and tested software for several projects, 
rncluding user interfaces for HP-UX system adminis- 
tration His work on the object action manager for 
HP-UX has resulted in a patent application. He is a 
coauthor of two articles and has presented several 
papers at technical conferences. He's also a member 
of the ACM and SIGCHI. Mark is married and has 
three cbildren His leisure interests include reading 
medieval history and literature, hiking, and playing 
acoustic guitar 
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A User Interface Management System 
for HP-UX System Administration 
Applications 

Developing applications to simplify HP-UX system administration has 
been made easier by the creation of a tool that addresses the needs of 
the developer. 

by Mark H, Notess 



The HP-UX* system administration manager (SAM) provides 
basic system administration functionality for standalone 
HP-UX systems and diskless clusters. The SAM tool simpli- 
fies HP-UX system adminLstration so that tlie administrator 
does not have to be a technical expert to manage an HP-UX 
system. Typical HP-UX system adminLstration functions 
such as adding a peripheral, setting up the spooler, and add- 
ing or deleting users are provided in SAM See "SAM versus 
Manua] Administration" on page 81 for an example of the 
simplification provided with SAM. 

By any measure, SAM is a large, complex interactive appli- 
cation. Of the approximately 150,000 lines of noncomment 
source code, almost half of it is directly related to the user 
interface. The SAM user interface consists of over 270 dis- 
tinct screens, excluding help screens and messages. A sub- 
stantial number of software, human factors, and learning 
products engineering hours have been spent working on 
SAM. 

Any interactive apphcation the size of SAM faces a msyor 
challenge in achieving a consistent user interface. User inter- 
face consistency includes many topics of concern such as: 

• Interaction paradigm 

• Selection and navigation methods 

• Position t labeling, and behavior of conunon elements 

• Relative layout of elements on the screen 

• Colors, fonts, cursor shapes 

• Message tyijes 

• Error handling. 

With many developers coding portions of the SAM user inter- 
face, it is impossible to achieve consistency without some 
mechanisms in place to assist in the process. Style guides 
have been useful consistency mechanisms, but rarely suf- 
fice- We adopted a "no rules without tools'" approach and 
decided to create a user interface tool that would enforce, 
where possible, consistency among developers. Where a 
semantic understanding of the interface was necessary, we 
developed a style guide, but the goal was to let the tool han- 
dle as much as possible. The other motivation for our tool 
was rapid development. Many general-purpose user interface 
toolkits are not easy to learn, are hard to use, and take a long 
time to master. Even user interface management systenis that 
are easier to work with are still general-purpose and contain 



a lot of features that are irrelevant for a given application or 
class of apphcations. We wanted SAM developers to be 
as productive as possible, so we wanted to minimize the 
following: 

• Time to learn the user interface tool 

• Time to prototype 

« Time to write working code. 

To achieve rapid development, we needed to hide the under- 
lying user interface technology! and provide an application 
program interface (API) that was at our developers' level of 
interest. 

The result of our concern for user interface consistency and 
rapid development is the object action manager (ObAM), an 
application-class-specific API for SAM and SAM-like applica- 
tions. The remainder of this paper describes the design of 
ObAM and reviews oiu preliminary results. 

Design and Development 

The old SAM user interface architecture did not shield de- 
velopers from the underlying user interface technology and 
as a result they had to learn ntore about Uie technology than 
they wanted. While we did have a libraiy of convenience 
functions such as message handlers, developers still found 
the API difficult to learn and a distraction from their primary 
focus — putting functionality in SAM. Providing SAM devel- 
opers with a user interface toolkit they could use meant that 
we had to study the requirements of user interfaces for sys- 
tem administration and then factor out common elements 
amd high-level constructs that would be most useful. Exam- 
ples of common elements used by every application include 
displaying messages to the user and validating user input. The 
following sections hst some of the higher-lever constructs 
we factored out. 

List Managemerft Much of system administration is a matter 
of adding, deleting, or modifying items in a list. For example, 
system administrators frequently select an object such as a 
device file, print job, or disk from a hst to perform some 
operation on. List manipulations such as filtering or sorting 
items can be useful for large hsts and require the same t^e 
of interaction independent of w^hat type of ilem is in the list 

T User interface techno logy incfudes components such as windoi,^' managers, disclay handteis, 
and graphfcs routines. 
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SAM versus Mantia] Admiiiistratioii 

Tfl illusuate ttie simpJjfication provided by SAM consider the foHowmg ejtample. 
wti^h shows what is involved m acfding a user called sarm to the group users 
without SAM and with SAM, 

WHkflfft SAM. The followiog keytx^d opefatians are reqtjired to atfd a user to 
^system 

1 Arid the new user to the group users by editing the fite /atc/froup. After the edit 
we have: 

users::2fl:i £jhn,hsrry,su e,k t v.sa ml 

2 Add sam to the/etc/pgsswd fiJe First make e backup copy of the file: 

cp /eto/p»s$wd /etc/passwd.old 

3. felit the /etc/passwd file to add a line for the the new user. The new line for 
samt might took Ifke: 

samt,.. J 20:300: sam thoma$,x2007:/ysafs/samtj/birT/ksh 

4. Cfeate a home directary for the user; 

cd ^lisers (go to user s d i recto ry) 

mkd f r s a mt [create a d irectory called sami) 
chowrt samt samt (set ownershipl 

chgrp users samt [set group ownership) 

c h mod sa mt | set perm issi on s for samt} 

5. Create a login envifor>ment for the new usef by copying the default profile fUe 
from /etc to the new users directory: 

c p /etc/d. p roftle /usa rs/sa mt/. p rDfile 

With SAM. After selecting the Add... item from the SAM Users and Groups 

Actions menu, the administrator fiffs in a form. If the default values on the form 
are adequate, all the administrator has to do is: 

1 . Type in a login name and select OK. 

Z Enter a password (twice) and again select OK. 

SAM does the rest. This approach avoids error-prone procedures such as editing 
files and typing command strings. 



Oescfipif on fjle 


Callbacks 



Dl^iei^t-AciiQii Manager lObAM) 



Task On'eiTtation. System admmistration is task-oriented A 
typical task sequence consists of selecting an object to oper- 
ate on, choosing the action to perform, supplying the neces- 
sary task paranieterSp launching the task, and verifying the 
success of the task. 

Selectors. Supplying task parameters can be done with a 
small set of user interface elements we call setectors. Exam- 
ples of selectors are a field for text entry, a list to choose 
from, or an option to toggle. 

Procedures. Some tasks consist of multiple, possibly inteixle' 
pendent or sequential steps. While doing the steps, users 
want to be able to figure out where they are in the process, 
redo or revisit earlier steps, and so on. 

The new SAM user interface architecture (Fig. 1) completely 
shields developers from the imde Hying user interface tech- 
nology. Developers have only one API to learn, which is tai- 
lored to (heir needs. With this architecture developers retain 
direct control over tiie Items most important to them while 
the ObMl controls the common elements. For example, ele- 
ment names, object attributeSj and messages are controlled 




Ocaphif^ Display 



Chfli^ctef-Based 
TerTnlnal 



Fig, 1- The BAM user interface software architecture, 

by the developer, and fonts^ window positioning, labeling, 
and control button layout are under Ob AM control. 

Choosing the Underlying Technology 

Most user interface tools only support one display tech- 
nology. With SAM, however, we wanted to pro\ide an OSF/ 
Motif graphical user interface while continuing to support a 
character-based terminal aser interface. After an extensive 
evaluation, we selected a third-party tool called Dialog Man- 
ager from ISAt to provide the platform on which to bidld our 
user interface management system. Dialog Manager provides 
multiplatform support (OSF/Motif, temiinals, Microsoft^' 
Windows, MPE/LX, Presentation Manager, etc), 16-bit inter- 
nationalization, and mn-time binding of tlie user interface, 

ObAM 

The msgor components of the ObAM are shown in Fig. 2. 
The description file defines the various screens used by a 
particular application and declares the functions to use in 
callbacks. These functions, which are associated with items 
on the screen %ia definitions in the description file, perform 
operations associated with those items. For example, a 
menu item for mounting a disk might eventually result in the 
execution of a C function containing a series of HP-UX sys- 
tem calls to accomplish the task. At run time the description 
ftle is read in and parsed, and a data structure is created 
with the appropriate hnkages to the developers' callback 
functions. The object-list executor is responsible for hsting 
objects on the screen (see Fig. 3) and facilitating user opera- 
tion of the display, and the dialog box builder is responsible 
for creating dialog boxes on the screen. 

Description File 

The description file allows developers to define the type of 
objects they are managing, the attributes of those objects, 
the actions that can be applied to the objects, and the inputs 
that are necessaiy for those actions to proceed. ObAM inter- 
prets the contents of the description file at run time to 
create all the SAM screens. 

The description file shown below is for a simple file man- 
ager apphcation. The ObAM descripfion file language is not 
a fidl-featured programming language; it contains only defi- 
nitions and variables. No sequencing, branching, or looping 
constructs are defined in the language. 

t informatEEHissYstfime for Cemputfirintegnarte Aytomstlsrerung GmbH. 
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PC Graphics 
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Fig. 2. T!iy riiaiji components in 
and assoeiated with ObAM. 



library "callbacks, si" /* points to shared library */ 

Qbjectjist_screen sample { 
label "Fiie Manager" 
status^, item li_path 
label "Directory:" 
subarea files i /* mullipie subaress may be defined 7 

label 'Files ■ 

entry callback fi_pwd()/*get path for current directory*/ 

/*define the format and labels to show on the screen 7 
table { 

init7bin/l1-a 'pwd' l/bin/grep -v 

'Motar I awk '{printSl; print S2; print 

S3; print S4: print $5; print £6; print S7; 

print $8; print $9 }'" 
attr fi perm { label "Permissions" column 1 } 
attr fijinks ( label "Links'' type numeric 

justify right} 
attrfi_owner ( Eahel "Owner" column 2 } 
attrfi_group{ label "Group" coiumnS} 
attrfi_size { label "'Size (bytes)" column 4 

width 12 type numeric justify right] 
attr fi_month { label "Month" column 6 width 3} 
attrfi_dayi label "Day'' column 5 type 

numeric justify right} 
attr fi_ttme { label '"Time/ \nYear" column 7 } 
attr fi_name { key label "File Name" column B \ 

} 
/^Actions associated with the Actions menu item */ 
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action fi_remove{ 
label "Remove" 

mnemonic "R" T Keyboard input satactor */ 
do "rm $(fi_name)" 
gray when no selections 

1 

action fi_cd { 

label "Change Directory" 

mnemonic "C" 

do fi_changedir 

} 

action fi_cd_!mmed { 

label "Change To" 

mnemonic "T" 

gray when no or multiple selections 

dofi_cd_toO 



) 



Fig. 3. The SAM screen that appears when the description file asso- 
ciated uilh our simple llle manager example is parsed and displayed. 



/* define dialog box for the change directory acbon 7 

task_dialog h_changedir{ 

label "Change Working Directory" 

/* when the OK button is setectod execute fi_cd_doit 7 

ok callback fi_cd_doitO 

ie)ft_edtt fi_cd„path { 

label "Mew Directory:" 

width 30 } 
} 

Fig. 3 shows the Dbjeot-list screen that Ob AM creates for 
tlris application. Tlie List, View, Options, Actions, and Help menu 
items arc put on the screen automatically. This is the same 
for other standard screen items, Object-hst screens provide 
list manipulation witli the List menu item. The Actions menu 
neni contains a pull-down menu with actions that can be 
perfonned on the i^elected object. Tlie View puil-tlown menu 
allows users to customize the list presentation through speci- 
f>4ng the attributes (columns) to display, tJie order to display 
the columns, the objects to filter out, and how to sort the 
data. 

Fig. 4 shows the dialog box defined by the taslc dialog 
fi_changedir in the listing above. When the action itent Change 
Directory is selected from the Actions pull-do wm menu, Ob AM 
accesses the task fuchangedir to determine what to do. Accord- 
mg to the defmitions in fi_changedir, wiiei^ the user enters the 
desired tiirector>^ ui the selector and pushes the OK button, 
Qie callback function fi_cd_dDit is executed. The callback 
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Fig. 4, Tilt? dialog box thai aprwars wlien tlie Change Directory action 
item is selected from the Actions mpjiii. 

function executes the chdir command to c hange to the new 
directory. 

For dialog boxes we wanted to lay out selectors (tejrt_edrt in 
this example) automafically rather than requiring develop- 
ers to worr>^ about positioning objects on liie screen. As we 
designed otir dialog-box builder, we realized it was unlikely 
that we rouJd do all the layout automatically because too 
much semantic knowledge of lite task is required to make 
the appropriate layout decisions. Otir solution w^as to lay ou! 
selectors in the order in which they appear in the desciip-^ 
tion file. In addition, if the developer defines more selectors 
than will fit on the screen, we add scroll bars to the screen 
automatically. ObAM also provides some simple layout coiv 
strttcts that allow specification of colimms, skipping lines, 
indenting, ant! grouping. In trading off control for flexibility, 
we chose to control only wiiere we had enough infonnation 
to control appropriately. 

AppUcation functionality can be connected to the screens in 
two ways: callback functions, w hie It can be used to get data 
from the .screens and perform at lions with that data, and a 
shell interface, wMcb provides direci af^cess to IfP-UX conv 
mands from ObAM. Direct calls to eottunands can include 
variables as arguments so that screen <:laia ctui be used in 
command exectition. The Remove action in the sample de- 
scription file uses this capabOity to remove one or more 
files. 

User Interface Library 

Within the developer's c all backs ^ the user interface librarj' 
(uilfb) functions provide* access to die data on the screens 
and allow developers to control a limited number of screen 
characteristics such as visibility and graying. The code be- 
low shows the C functions associated (\ia a shared library) 
with the simple file numager example defined above. 

imfi_£d_dait{| 

( 



charbLjlil0251; 

uLg^t.tiatal "fi_cd_path ^buf); 
chdir(bijf|; 
fEturniO); 
}/*fi_crd„doit*/ 

int fi_cd_to() 
i 
char bufl1025l; 

ji_9et_obiect_field("!Lnanie",bTjfh 

chdirfbufl; 
return(0}; 

l/*fLcd..doitV 

imfLpwdO 



char buf!lOZ5]; 

ui_set_st3tiis{ 1 ,getcwdfI>af>1tK5Jh 
retym(Qh 
}rn_pwd*/ 

Evaluatiftii and Disc-ussion 

Since ObAiVl has been in use for SAM development, our ini- 
tial evahiation suggests that we have l>een successful in 
achieving our goals. 

Developer Learning, learning the new user interface tooLs is 
an order of magnitude faster and easier than the old tool. 
Users have iTported learmng times of two or three days for 
the nevr system as opposed to two or three weeks for the 
old system. 

Prototyping. Aix entire functional area of SAM can now be 
proiot>ped in a ciay or two. Becatise ObAM supports using 
HP-l^X commands directly as w^ell as C callbacks, a con)- 
pletely hmctional protot,vi>e can be bihlt without the devel- 
oper having to wTite and compile any C code. Turtung an 
ObAM prototype into an ObAM product is evolutionary. The 
screens can be constructed rapidly, and the ftmcrionality to 
suppoirt the screens can be added ii> ere men tally. 

Development. Developer satisfaction is much higher with the 
new^ tools. Our old development tools required us to central- 
ize screen creation responsibilities. If we had allowed devel- 
opers to create tlieir own screens with our old system, we 
would have paid a heavy price for having everyone learn the 
cumbersome screen creation tool we had available, and it 
wonki have been mttchmore difficuli lo enforce consistency 
across all the areas of SAM. C onsequenlly, in Qie old system, 
most of the SAM screens w^ere created by one engineer. Re- 
quests for new screens or changes had to be ftmneled 
through Tl\at. one person, even if tlie need was as trivial as 
changing the i\imie of a callback or lengthening a field. In 
contrast, ObAM puts developers in control of the parts of 
the interface that are most important to them and redtices 
time-consuming <lependencies between engineers, 

Coosistencv^ Our consistency issues can be divided into two 
categories: si^niiyitic and syntactic. Semantic consistency is 
acliieved by maj>pmg different sets of functiotiality onto 
ObAM culpabilities using the sajne set of rules. This mapping 
has to be done l)y hand because ObAM Is not Uitelhgent 
enotigh to detennine the attributes of a printer (jbject, or to 
figure out w^hat steps are needed to add a tlisk. We have pro- 
duced a SAM user interface style guide to help developers 
with these decisions. Syii tactic consistency is achieved by 
ensuring that similar user interface elemeni.s look and feel 
similar. ObAM hk\s made <Hir syntactic consistency effort 
much easier. ObAM code knows, lor example, that a push- 
button label should be followed by ".-,*" if pressing it leads to 
another screen; the developer doesn't have to ti\ink about 
this decision. 

An imstated goal of oiu* ObAM work was to create some- 
thing that would Ive useful beyond SMI. SAM itself is not so 
much a single ajjplication as it is a collection of related ap- 
plications such as a file system mtmager, a user accoimts 
manager, a cluster configuration tool, and so on. We know 
that other projects have similar needs for rapid developoieru 
of consistent user interfaces. Over the years, the SAM team 
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has received ntany mquiries about how to create SAM-like 
user interfaces. This interest suggests tJiat we have achieved 
an application-category user interface management system, 
not just a SAM-specific user interface management system. 

Areas for Improvement 

ObAM is still in its early stages, but we have already found 
areas for improvements and new features. Some of these 
areas mclude: 

More factoring is needed. Some messaging and error han- 
dling is repetitive enough that we could supjion it in the 
description-fdej further reducing the amount of appUcation 
developer code. 

Performance could be improved by precompiling screen 
descriptions. Our current architecture requires two separate 
parsing cycles for task dialog descriptions. 
Better enor messages would aid learning and prototyi^ing. 
Currently, Ob AM identifies the point of fail me when parsing 
a description file, but it could provide more hel|>fui error 
messages. 

Conclusion 

Our success in creating an applicatioU'Specific user inter- 
face management system suggests that other tjpes of inter- 
active apphcations could speed development and improve 



user interface consistency if an appropriate system existed 
thai was tuned to the requirements of each type of applica- 
tion. Application-specific user interface management systems 
are likely to be beneficial when the target user interface has 
the following characteristics: 

' Large size (many screens) 

' Factorabiiity (many similarities between interactions) 
' Multiplatform (more Ifian one user interface display 
technology must be sutJpori edj 
■ Developers do not have to be user interface designers. 

Ac kiKj wledgm ent^ 

ObAM wijs a team effort. Significant R^D contributions 
came from Mike Conca, Tammy Heiserman, Mike Kuigdom. 
and Scott Warren^ with Paula Curtis and Dan Castle provid- 
ing hum^m factors input. Management support came from 
Aland Adams ttie SAJVl project maiiager 

HP-UX is based on and Is ccmpatible mh UNIX System Laborstorles' UNtX* [jperating system 

It also ramp I IBS with X/Open's* XPG3, POSfX 1003.1 and SVIDZ mterface speaticaiions. 

UNIX i^ a ^i^tefed trademark oi UNIX System Laixiratories Jnc, in the U3A. and other coumries, 
X/Dpet) i& a trademark of X/Open Company U mi tad m the UK and othsr coumriea. 
Microsoft is a U.S. registsred trademark of Microsoft Corp, 
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